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 discussion 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. Regards, Gennadiy.