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: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-10-27 02:51:37

----- Original Message ----- 
From: "Robert Ramey" <ramey_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, October 27, 2010 7:23 AM
Subject: Re: [boost] Is it time for another bug sprint? (Post 1.45 release,I mean)

> 
> 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
> 
> 
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>