Re: [boost] Is it time for another bug sprint? (Post 1.45 release, I mean)

Subject: Re: [boost] Is it time for another bug sprint? (Post 1.45 release, I mean)
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-10-27 01:23:43

Marshall Clow wrote:
> On Oct 26, 2010, at 7:24 PM, Jim Bell wrote:
>>
>> On 1:59 PM, Marshall Clow wrote:
>>> What do people think?
>>
>> What's the benefit of releasing 1.45 before a bug sprint?
>
> The point of the bug sprint is to get the number of issues that have
> piled up (in the Trac) down to a more manageable level. Some of these
> are bugs, others are feature requests, documentation
> updates/requests, and just misunderstandings.
>
> Right before a release is not (IMHO) a time to be making many changes
> to the code base. It's a time for care, and limiting change (and
> risk).
>
> Doing bug sprints (I was going to abbreviate that but I decided that
> BS was not the best acronym) right after a release gives the fixes
> were made in the sprint "time to bake" - to make sure that they fix
> the reported problems (and not introduced more).
>
>> Particularly with the regression test matrix having as much yellow
>> as it does?
>
> The large abounds of yellow in the regression matrix is a different
> matter - and I suspect that the release managers are worrying about
> that.

I've always held the view that each release should be strictly better
then the previous one.  I interpret that to mean

a) In current code - less bugs than the previous version
b) 0 or more new features
c) no more yellow columns than the previous version.

Only under these circumstances should code be moved to the
release branch from the trunk.  So the a), b) and c) above
should be true for every release regardless of when it's scheduled.

As far as the serialization library is concerned right now.  There
are changes in the trunk that can/should be moved to the release
branch and this will be consistent with a, b, and c above.  There
is one change which has caused regressions in the trunk and
this should not be merged into the release branch.  We should
be focusing on release branch testing now.  The mechanics
of moving all the changes but one is somewhat tedious.  We'll
have to decide very soon how to do this.  I made the mistake
of not merging in the changes into the release branch before
a higher risk change was made in the trunk.    We'll decide how
to address this soon.

Robert Ramey