Boost logo

Boost :

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:

Boost list run by bdawes at, gregod at, cpdaniel at, john at