Re: stable/2.14 and fixed_2_x_y

[Carl Sorensen]

On 4/17/11 2:33 AM, "Graham Percival" <address@hidden> wrote:

> On Sat, Apr 16, 2011 at 12:01:43PM -0600, Carl Sorensen wrote:
>> On 4/16/11 5:02 AM, "Graham Percival" <address@hidden> wrote:
>> 
>>> If you fix something in the issue tracker, mark it fixed_2_15_0.
>>> Carl will add fixed_2_13_61, _62, _63, _64, etc., when he
>>> cherry-picks the patch to stable/2.14.
>> 
>> Also, please set the status to Started, rather than Fixed.  I'll set it to
>> Fixed when I cherry-pick it to stable/2.14.
> 
> I disagree; for example, look at
> http://code.google.com/p/lilypond/issues/detail?id=1609
> If we only mark it "started", then it will still show up in the
> general "open bugs" list, and in the "patches left to review"
> list.
> 
> Instead, I think we should mark something as "fixed" if the patch
> is in git master, but add a "backport" label.  You will remove
> that label when you actually do backport it, and I'll check to see
> if there's anything with "backport" before making any releases.

OK, I like this idea.  But I reserve the right to remove the backport label
if I don't feel like it's best to backport a given patch.

> 
> One consequence of this is that the bug squad's "verify" step
> becomes more important, but at least it doesn't drive a huge spike
> through normal development and bugs.

Verify can't happen until it's backported.  So we'll have a large number of
issues that are fixed but not verified.  I'm OK with that; I can do a grid
view of issues to verify to see what needs to be dealt with.

But it would be nice if the Bug Squad could verify any issues that are fixed
pre 2.13.61 so that the list of issues to verify is the backport candidates.

> 
> 
> NB: I'm still using Carl's policy unless he changes his mind.
> When making the patches countdown or looking at the existing
> Critical items, I can just manually check every item.  There
> should be less than 10 such items at any time, so it's not a huge
> amount of extra work.

I agree with this policy in place of my original policy.

Thanks,

Carl