Preparing for a point release

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> > Remember, Linux used to have stable-branch releases.  It no longer does
> > because Linus noticed the same failure mode I did.  When you start
> > cherry-picking onto a "safe" branch you increase the expected time to
> > discovery of any bugs on your unstable branch.  This is not a good trade in
> > the longer term. 
> 
> I think that depends on who your users are.
>
> Releasing current HEAD rather than using branches turns all your users into 
> testers.  Some people put a high value on stability.  If all you do is 
> release HEAD, then some distros will have to dig out the critical bug fixes 
> for their customers who value stability.

I think that's an acceptable consequence. We could lubricate the process
with low overhead by flagging things we think are urgent functional
and security bugs in the NEWS file and the commit for the change.

Maybe tag them like this - "URGENT BUG:"

We can also create a low-traffic announce list for alerts on critical patches
and invite distro packagers to subscribe to it.

> In any case, we need a plan for how to get out a security bug fix ASAP when 
> HEAD is far from stable.  (The plan might be cross that bridge when we get 
> there, but we need to think about that case.)

I think you just elicited a plan.  I like it - it means we don't have
to choose the one stable release for everybody, we can in effect let the
distributors choose a risk profile appropriate for their customers.

> In another thread, you asked me to work on release procedures.  I'm rounding 
> that up to include overall project management - you need a context for 
> how/when to do a release.

Friendly amendment cheerfully accepted.  You do remember that I tried to
recruit you to manage this project way back near the beginning, yes? :-) 

> My first step for how to run a project would be to identify your customers so 
> you can ask them what they want.  Right after that would be to make sure that 
> they understand that they have to help with testing and hence are tangled up 
> with the release process.

Please do keep thinking about this.  Remember that for the plan to be useful,
each step has to be actionable and have a success-failure criterion.  If you're
going to say "identify your customers: the plan has to specify how we can
do that.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.