Re: [boost] [1.35.0] Release criteria compilers

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 
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