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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk