From: Rozental, Gennadiy (gennadiy.rozental_at_[hidden])
Date: 2004-08-25 21:59:41
> 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?
> 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
> > 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. 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
we may decide to go ahead with release on previously defined terms, ignoring
issues causing release to postpone).
Please, understand that I am not trying to find responsible. But I also
don't find this uncertainty acceptable.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk