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