Boost logo

Boost :

Subject: Re: [boost] Is it time for another bug sprint? (Post 1.45 release, I mean)
From: Jim Bell (Jim_at_[hidden])
Date: 2010-10-27 07:56:16

On 1:59 PM, Robert Ramey wrote:
> 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).

I'm with you on letting changes "bake."

But aren't you suggesting that all those bugs demanding the sprint
should go out in the next release?

>>> 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.

Who are the release managers, and are they worrying about it? I'd love
to hear what they're thinking.

And I hope they're NOT thinking, "well, the calendar says 'release' so
here we go..."

Do they publish their thinking along the way?

> 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.


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