Re: [boost] The Release Manager's Point of View

From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2007-06-04 23:22:22

Gennadiy Rozental wrote:
> "Stefan Seefeld" <seefeld_at_[hidden]> wrote in message 
> news:4664821B.5060506_at_sympatico.ca...
>> Gennadiy Rozental wrote:
>>
>>>> * Bugs attributed 1.34.0 <http://tinyurl.com/2cn7g6>, and only a small
>>>> number of them are targeted for 1.34.1.
>>> I see only 6 bugs assigned to 1.34.1. To be frank with you I don't see 
>>> why
>>> do we need to hurry with releasing them.
>> I'm not sure I understand the question. Why these bugs are assigned to 
>> 1.34.1 ?
>> Because they are regressions / showstoppers that have the highest 
>> priority.
> 
>       284 pool::purge_memory() does not reset next_size assigned shammah 
> Bugs Boost 1.34.1 None
>       958 [doc] The "Getting Started" page mentions incorrect library names 
> new dave Bugs Boost 1.34.1 Building Boost
>       964 [filesystem] missing documentation or bad links new -- Bugs Boost 
> 1.34.1 filesystem
>       965 [doc] boost::variant tutorial - final example uses v1,v2 should be 
> seq1,seq2 assigned ebf Bugs Boost 1.34.1 variant
>       982 x64 documentation for windows new -- Support Requests Boost 1.34.1 
> Building Boost
>       991 [pool] new -- Bugs Boost 1.34.1 None
> 
> '
> 
> Which of these are showstoppers?

I have no clue. I didn't assign them to 1.34.1.

>> Or why the people aren't focusing on 1.35 now ? (I guess because it's 
>> always
>> more fun to focus on features an not bug fixes.) Etc.
> 
> Why don't we fix'em in 1.35?

because that is mere terminology. The question is not how we call the next
release, but what to focus on now. Should the scope be regression / bug fixes,
or new features ? (It is evident that for us developers new features are always
more appealing. But that's not how we can build a reputation for high-quality
software.

> 
>>>> * We don't test the build and install process.
>>> What do you want to test? In any case it doesn't make release "unstable"
>> The release (well, in fact, packaging) process was retarded because a 
>> substantial
>> number of bugs only turned up during that very last phase, simply because 
>> that
>> wasn't tested at all. Had packaging (etc.) be part of the regular testing 
>> procedure
>> those bugs weren't present, at that time in the release process.
> 
> I guess it would be nice. Do you know how implement these tests in practice 
> (I mean without human involvement)?

As Rene and Doug point out, the first thing to do is run the same set of tests
that are already there, but not against a full boost source tree, but against
a installed boost version. That lets us detect errors introduced during installation.

> That's the problem. No one seems to make an effort to read what I propose. 
> My solution assumes that no testing is done during release, none whatsoever. 
> Only components that already tested and individually released by developers 
> will go into umbrella boost release.

OK, that's an interesting point, but only displaces the problem. Then we
need to discuss the release procedure of those components, and talk about
how these are stabilized. Etc.

Regards,
                Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...