Re: [boost] Re: Regression report for Releases?

From: Jeff Garland (jeff_at_[hidden])
Date: 2005-03-20 19:22:12

On Sun, 20 Mar 2005 18:19:33 -0500, David Abrahams wrote
> I think it should also be available from an obvious link when you go
> to get information on or download the current release.

Sure.
 
> > Do we even have a way of tracking the check-ins?  
> 
> CVS?
> 
> > That might be a good first step.  I notice that sourceforge seems to
> > be generating some sort of email when I check-in, but I don't know
> > of a way to subscribe to the changelist.
> 
> We can set up a mailing list for it to send to, if you want to see
> those.  But I don't think that would solve the problem by itself.

I don't know of a CVS command that would give me all the changes to the
repository in the last 12 hours (there may be one).  So if something breaks
and I didn't check anything in, I might want to find out who made the change
and fire off a heads-up email to them.  So I think the mailing list might have
some utility. This might be particularly relevant to the folks running
regressions b/c as some if they see a library start to fail it would be much
more obvious who's to blame...
 
> > I agree with him about wanting to use the compiler to find breakage,
> > but the problem is that his particular library is one that many
> > libraries depend on.  As a result, it really needs to stay stable
> > during the release period to ensure that we don't have 2 days of
> > downtime while something Boost-wide is broken.  
> 
> If we could initiate tests on a branch by request we wouldn't have
> this problem; he could run all those tests before merging.

Yes, but there will still be some limit.  If we are 3 days from release and
the test farm is humming away on both mainline and the release branch we
proably won't have infinate bandwidth to test developer branches.  But I agree
totally that regression testing on developer branches is a huge and powerful
feature...
 
> > So I really think
> > that we need to start thinking about a dependency analysis of Boost
> > and an added freeze date for 'core libraries' that need to stay
> > stable during the release process.  
> 
> I'd really like to avoid that.

Why, what does it hurt?  Core library developers just need to adjust their
timeline thinking.  Think of it this way.  All releases have a certain cycle
to them.  Stabalizing the core is one phase.  So the release timeline looks
something like:
-45 days core library freeze
-30 days last new library added
-15 days branch for release
-2 days all code frozen (doc changes ok)

Back in the ideal world, I'd like to see Boost releases become really
inexpensive in terms of time.  In combination with some of the other things we
are discussing we should be able to normalize the process to the point where
the length of the release timeline is very short -- I'd say 15 days or less. 
We have a long way to get there though...

Jeff