Markus Schöpflin wrote:
Jeff Garland schrieb:
Let me put it another way. We will continue testing and fixing on the all compilers/platforms for which we have volunteers. The difference is, that we aren't going to hold the release up to ensure that less standard compliant compilers are all green.
Do you have any evidence that the last release has been hold up because of less standard compliant compilers?
See my response to Peter -- simply less things to get right before the release ships.
(Note that I already mentioned the following in another mail which didn't make it to the list up to now so I'm going to repeat it here.)
My impression as a long time regression tester has been, that the last release simply was held up by a lack of time and/or interest in getting the release out of the door. I know some people have put a lot of time and effort in the release, but I also noticed (in the first nine months after the release branch was created) that nothing visible happened for weeks (which allowed me to fix a lot of things for the platform I care about), only to wittness some small or not so small modification causing major breakage for many platforms. And things would stay like this for a few weeks, before someone seemed to care.
There's many many reasons behind the 1.34 release delay. Nothing visibly happening when something major is broken simply won't be allowed for 1.35 -- we will revert changes if need be to get this release done in a reasonable time. That includes not including new libraries that can't pass with the core set of compilers.
By reducing the number of platforms we can reduce the cycle time for developers to be sure changes are working. This allows us to get new libraries and fixes released to the whole of the Boost community in a more timely fashion. Right now we are essentially delaying releases to provide for a minority of our users.
Because of the things I have written above, I challenge the statement that it's the support for the exotic or less compliant platforms that has held up the release.
Keep in mind we have something like 7 or 8 libraries to add into 1.35 since library additions have essentially been disallowed for 1.5 years. We can't let this continue -- we have to catch up and get these libraries available for Boost users. Any failures in 'exotic' platforms slow that process down and ultimately delays the library availability for everyone. If we get quarterly releases going correctly this whole issue will go away because the failures for the platform you care about can be in the release in a few months...instead of years....
And ultimately, these compilers/platforms aren't left out in any way because fixes/ports can go into the next quarterly release. The main thing we need to do at this juncture is 'whatever it takes' to break out of the current release quagmire -- we have important libraries and fixes that have been backed up for over a year now.
I understand that you don't want to repeat the fiasco of the last release, but I think right now you're throwing the baby out with the bath-water.
I don't believe so. I think we are making precisely the attitude change we need to get the release process working. The bottom line is that we need to take decisive action with the release process or Boost as a project will fail under it's own weight. I'd ask that you keep and open mind and give this process a chance -- if it fails we will try other things, because this really, really needs to be fixed. If the process succeeds I really believe everyone will be better off -- including the folks on exotic platforms. Jeff