From: Jeff Garland (jeff_at_[hidden])
Date: 2007-10-05 19:37:16
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
> (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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk