On 07/15/2010 07:07 PM, Amos Jeffries wrote: > Redirected to dev since this is off-topic for the bug now. > > [email protected] wrote: >> http://bugs.squid-cache.org/show_bug.cgi?id=2651 >> >> --- Comment #17 from Alex Rousskov <[email protected]> >> --- >> (In reply to comment #16) >>> Alex, please close on commit and mark with the version to be ported >>> back to. >> >> I think we should not close until the fix is ported and committed to the >> current release branch (or you decide not to port). Otherwise, it may >> be too >> easy to overlook the need for porting. Also, most users do not care >> much about >> the trunk state. For them, the bug is not fixed until the current >> release has a >> fix. >> > > As long as the bug is quoted in the commit message the changeset > maintenance pages used for porting make it trivial to find and check. I > check every bug fixed before porting to see how relevant it is and to > add the "applied to X" comments. > > I look for both the Version of how far back its actually needed and how > close to a feature it is, so how hard I should work on getting it to > port. The Target Milestone gets changed by me after porting to the > version where portage stopped. So its not formal, but Target is usually > for me the version where it's currently fixed if closed, or the version > which needs to be prioritized for a fix to be made working against if open. > > As for the closing itself, there are a lot of bugs which get fixed in > incremental parts and it's very hard to follow whether the bug is fully > fixed or partial without being one of the fixers. I've been burned > before with closing other peoples bugs myself after they committed one > of a series of patches. The closing of the bug is my main indicator now > that the fix has actually been finished in the opinion of the dev who > fixed it and is fully in trunk, so to start the porting process. > > If the bug is still open it becomes a matter of chance whether I have > time to read the full bug report and understand it before porting. Often > I do, but that is no guarantee.
OK, I will start closing after the trunk commit since that works better for you. > Where the patch applied to trunk does not easily apply to the lower > versions for users wanting to patch. Then by all means feel free to help > out both the users and myself by attaching a port patch before closing > with a trunk fix. Sure. I often have lower version patches based on 3p1-plus or 3p0-plus branches that I maintain on lp, but I hesitate posting patches that have not been applied or tested with the [latest] official release. I try to provide an lp revision ID so that you have an option of merging the fix from those public branches as a starting point. Cheers, Alex.
