RE: [boost] Re: [1.32 Plan] Stalled forever?
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.
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
On Fri, 27 Aug 2004 19:30:41 -0500, Aleksey Gurtovoy wrote
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 have to say, that the transition over the last month in the regression testing system has made this alot of work to keep on top of. There has been quite alot of churn in the toolset names -- adding of new compilers vc8, tru64, etc. Just when you think you have everything marked a new one pops up or an old one changes. I'm not saying the new system is bad -- on the contrary I think it has enabled us to run more tests and see failures more clearly than ever before. It's my 'guess' that alot of the failures that are there now have always been there, but we just haven't seen them because we weren't running the tests or it was too hard to find...
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.
So clearly the mainline isn't quite ready for release, but I get a sense that it is alot closer than you are implying -- as long as you aren't looking for an all green board. The one thing that I'm not able to see in the new system is regressions from 1.31 -- before we decide the mainline is shippable I think we really need to assess it compared to the last release. Not sure how to do that now. Also, in my view there's probably a small core set of 'almost compliant' compilers that we should be driving toward 100% passing (or at least green): VC7.1, gcc3.3, Intel 8, cw9.2. As I recall (see below) VC7.1 was at 100% on 1.31 and I think there's some set of compilers that are good enough that users should expect boost will work with them. After we've achieve that goal we can worry about problems in the other compilers... And BTW, what happened to the 1.31 regression test reports on the webpage? It's useful to have them around from time to time ;-) Jeff
participants (3)
-
Aleksey Gurtovoy -
Jeff Garland -
Rozental, Gennadiy