PROPOSED, change of stance, release metronome

[Hal Murray]

Kurt's comments look good.  This is what I was typing in while that was in 
the pipeline.

fallenpegasus at gmail.com said:
> I propose that we move to a scheduled release model, with the addition of
> security fast releases. 

I think it's more complicated than that.

There are several tangled ideas.  One is release.   The other is support.  
You haven't said anything about support yet.

What is the target audience for a release?
How long are we going to support a release?

I'm assuming support for older releases means apply security fixes.  If we 
have releases every 2 weeks, that turns into a lot of work.  I think that 
combination means we only support selected releases.  One of the main tasks 
of the project manager is to figure out which releases to support.

You could say the same thing with different words.  A release is something 
that gets supported.  The things that go out every 2 weeks need a different 
term, maybe mini-releases or dev-releases.

If we have supported releases every 6 months or so, I think we should spend a 
few weeks before the release concentrating on testing and checking the 
documentation.


This is handwaving, but I'll start with there being 2 classes of users.

The first is bleeding edge.  Developers can grab the latest from git.  In 
this context, testers count as developers even if they don't write any code.  
Support consists of going forward.  Old releases are never fixed.  They are 
supported only in that you can get them from git to back out of recent 
changes if they break something in your environment and/or you are bisecting 
a bug.

The second target is distros.  Within a distro, there are probably several 
sub-targets.  Many distros have 3 "supported" releases.  I'll call them 
testing, stable, and old.

The stable release is the one most users are expected to run.  The old 
release is the previous stable.  It stays around to give users plenty of time 
to upgrade to the new stable.  The testing area is for testing new releases 
from upstream and whatever local changes they make.

Many distros have releases every 6 months to a year.
Ubuntu LTS supports selected releases for 5 years.
  https://wiki.ubuntu.com/LTS 
RHEL goes out to 10 years.
  https://access.redhat.com/support/policy/updates/errata/

In an ideal world, we would support all the releases that our users are using.  In that context, support means security fixes and major bug fixes but not feature updates.  (The idea with not adding features is to reduce the risk of breaking something.)  If we do things right, after we release a security fix, our users can just grab the fixed version, test it, and release.

If distros are helping us test our code by running our 2-week releases in their testing area, we need to coordinate things when they make a release.  We need to do a release when they start their pre-release testing and they need to use that release and stop grabbing our 2-week releases.

With some coordination, we could reduce the total workload by getting several distros to use the same release(s).  If that happens, it makes sense for us to support the old releases since the work of fixing a security bug only needs to be done once.




-- 
These are my opinions.  I hate spam.