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

From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2007-06-04 19:34:23

Gennadiy Rozental wrote:
> "Rene Rivera" <grafikrobot_at_[hidden]> wrote in message 
> news:46647897.5030204_at_gmail.com...
>>>>> The proposal seems to assume infinite resources in testing.
>>> Which particular part?
>> On-demand testing, testing of breaking-stable branch, continuous testing
>> of stable branch, all with high-availability and high-. Currently we can
>> only manage partial testing of *1* branch, in one build variation. And
>> now we are talking of testing at least three branches at once.
> 
> My solution doesn't require ANY of that. Let me repeat NONE.

Gennadiy, with all due respect, I wasn't talking about your solution. I 
was talking about Beman's proposal. I think it is a wasted effort to 
consider proposals and solutions that I can read concise documentation 
for. It's almost impossible to comment on them otherwise. So for all 
those thinking that their way is better, please write it up and we can 
consider them individually.

> Well, 
> high-availability/quick responce would be nice. But it's optional.

According to Beman it's essentially required.

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

The *whole* page is 1.34.0 issues, and only 6 of the 47 are slated to be 
fixed. One of them in particular, the one I've been trying to fix for 
days now #1025, gives incomplete installs for Windows Cygwin and MinGW 
users. This is something we don't detect, because we don't test Boost 
from a users point of view.

>> * The inspection reports 193 non-license problems, and *1059* license
>> problems.
> 
> This is not a showstopper IMO. 1.34.0 in the same state isn't it?

I didn't say anything about "show stopper". I said it doesn't make it 
"stable" according to Beman's definition in which he states that 
clearing the inspection results is part of making it stable.

>> * We don't test the build and install process.
> 
> What do you want to test? In any case it doesn't make release "unstable"

I think first part of that was already answered. Yes it makes it 
"unstable" from the POV of users. If you can't guarantee that users will 
get an install they can use, how can it be stable?

>> * We don't test libraries against an installed release.
> 
> What do you mean?

I think Doug answered this... We don't test the *using* of Boost 
libraries. We only partially test the conformance of the code to 
expectations of library authors.

>> * We don't test, to any effective means, 64 bit architectures.
>>
>> * We don't test, to any effective means, multi-cpu architectures.
> 
> Would be nice ... in future releases. It doesn't make current unstable.

It makes it unstable as soon as user asks why Boost doesn't work in 
64-bit mode. And it makes it unstable when users complain that their 
program crashes in a Boost library when they run it on a dual-core, or 
dual-cpu, machine both of which are common now.

> Let's me clarify again: do you believe 1.34.0 can't be used as stable 
> starting point? If not, why?

Yes, it can't be used for a stable starting point. Because it is not 
proven stable, with testing, under the conditions users would operate under.

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo