Re: [boost] Proposal for radically altered approach to releases

From: Jeff Garland (jeff_at_[hidden])
Date: 2006-05-14 17:19:50

On Sat, 13 May 2006 12:34:41 +0400, Vladimir Prus wrote
> Jeff Garland wrote:
> 
> Huh? Sorry, this is FUD. Though V2 initially caused quite a number 
> of issues on it's own, they were fixed pretty quickly, and the 
> remaining issues can be knocked down quickly too.

Hi Vladimir -

Please, don't get upset -- I'm not trying to single you out -- there's plenty
of good reasons for the release delay I'm sure.  And I'm sorry, you're right I
shouldn't have used an example I don't really have first hand knowledge of --
I haven't paid attention enough to know if V2 is really stalling the current
release.  Only Thomas can say.  

> The problem is that I don't see any effort to close other issues. 
> Let me get specific:
> 
>   - There's date_time failures with FelipeAlmeida and Bronek_office 
> runners,    which use V1. How V2 prevents you from investigating 
> them? 

Nothing at all.  I've been a bit busy so I haven't looked lately and Doug's
failure nag seems to have gone away.  Of course with no changes in date-time
for a month and barely any since the last release it's probably a problem
elsewhere, but who knows.  I'll try to look today.  Of course even if all the
regressions were fixed today, someone would realize we need to run the license
checker and that would spiral us into another week of fixing, etc, etc.

>  - The concept_check and mpl libraries fail across *all* 
> toolsets. I've    reported this here, twice, and nothing is still done.

Yep.

> How about reverting date_time to the version that was shipped with 
> 1.33, right now, on the grounds of there being test failures?

I'd be fine with that if the build manager felt it was necessary to get the
release done.  I wouldn't make the suggestion if I wasn't willing to have it
applied to myself.

> Sorry if that sounds rush, but I simply don't think that "revert 
> war" on mainline is a best way to handle anything.

Sure it would.  It would change the process in a way that would stop the
endless delays and waiting for everything to be fixed.  Since the process
would be much faster there could be more releases and the fact that date_time
or anything else was reverted wouldn't be such a big deal.  Again, I'm not
suggesting this policy for the current release (frankly it's too late), just
pointing out an alternative to the current process that I believe would make
the process shorter.
 
> The "stable branch" idea from Beman, on the other hand, sounds quite
> feasible. It might be even better if merges to stable branch are 
> done by release manager only, so that he gets full control of what 
> goes to release.

That sounds vaguely like what I was proposing ;-)  As I tried to say, I'm
generally a supporter of Beman's proposal because it basically enforces what
I'm talking about -- fix it or it's reverted.  Until we get serious about
enforcing that no one will pay attention.
  
Jeff