On 07/15/2010 07:07 PM, Amos Jeffries wrote:
> Redirected to dev since this is off-topic for the bug now.
>
> bugzilla-daemon_at_squid-cache.org wrote:
>> http://bugs.squid-cache.org/show_bug.cgi?id=2651
>>
>> --- Comment #17 from Alex Rousskov <rousskov_at_measurement-factory.com>
>> ---
>> (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.
Received on Fri Jul 16 2010 - 15:03:21 MDT
This archive was generated by hypermail 2.2.0 : Fri Jul 16 2010 - 12:00:08 MDT