Re: [boost] Re: [1.32 Plan] Stalled forever?

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2004-08-27 19:30:41

Rozental, Gennadiy writes:
>> Gennadiy Rozental writes:
>> > I would like to second that.
>> >
>> > Two month ago I was told that I had to freeze any development yet 
>> > another month ago. Now we still nowhere and I still couldn't move a 
>> > finger.
>> 
>> 1) Release or not, any major new development should happen on 
>> the branch.
>
> I could do my own development anywhere, even keep files on my hard
> drive.  How am I supposed to test it?

Until it's stable enough, locally. You could also ask regression
runners for the platforms you don't have access to to do a run on your
branch when you think it's getting ready for the prime time. But the
main trunk is not a testing ground for experiments.

>
>> 2) At least please take care of the unmarked failures in 
>> Boost.Test before
>>    claiming that you've done your part for the release.
>
> Does it say anywhere that I am required to? All the failures either
> expected or too minor to jump to fixes now and disturb the
> release. I had enough unexpected headache with things I did decide
> to fix

You don't have to *fix* them if you consider them minor. But nobody,
including the library users and the release manager, will know whether
they are minor or not until you *mark them up* as such, preferably
with a short note explaining the cause and the consequences.

>  
>> > I understand that it may be caused by book preparation. But 
>> should we 
>> > necessarily need to use namely this release?
>> 
>> Yes. We have to use a coherent set of sources that contains 
>> the new version of the MPL, and this is what this release is 
>> going to provide us with, in particular.
>
> We may've published this release month ago with MPL changes. 

Of course we couldn't. Look at the main trunk state.

> And publish another one (may be patch release) month from now with
> new MPL.
>  
>> >
>> > Let at least set a policy for open information: if for whatever
>> > reason release needs to be postponed lets announce it and set a
>> > new date.
>> 
>> There *was* announcement of the release delay. The new date is 
>> going to be set as soon as MPL is in the main trunk.
>
> I don't believe "release postponed until further notice" is good
> enough. The same time new schedule needs to be proposed and agreed
> upon (or after discussion we may decide to go ahead with release on
> previously defined terms, ignoring issues causing release to
> postpone).

Another release might be done different. This one is feature-based,
and within its external constraints, it's going to be released when
it's "feature complete".

>
> Please, understand that I am not trying to find responsible. But I
> also don't find this uncertainty acceptable.

If you want to reduce uncertainty, please consider contributing to
bringing the main trunk to a releasable state.

-- 
Aleksey Gurtovoy
MetaCommunications Engineering