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

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2007-06-04 19:28:20

"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?

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

>>> * 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)?

In any case This problem is separate doesn't make boost source code 
unstable, which was the point of this list.

>>> * We don't test libraries against an installed release.
>>
>> What do you mean?
>
> In the sake of modularity (for example), take a boost library X, and test
> it in isolation, against its prerequisite boost libraries installed, not
> part of the same source tree.

Again I don't see how is it related to the stability of the boost source 
code, but my approach supports this naturally

>>> * We don't test release versions, even though this is the most used
>>> variant by users.
>>
>> We shouldn't be doing this at all IMO. NO testing during release.
>
> You lost me.

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.

Gennadiy