PROPOSED, change of stance, release metronome

[Mark Atwood]

HI!

It's obvious we have a lot more thinking and talking to do to work out how
to do releases that are good for distributions, and how to do Long Term
Support releases.

I was unclear about the scope of my proposal for 2 week releases.  We
should not have a cadence that fast once we are at a 1.0 or beyond, the
fast fixed cadence is while we are still at 0.9

..m


On Sun, Mar 13, 2016 at 10:51 PM Hal Murray <hmurray at megapathdsl.net> wrote:

>
> 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.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160314/5c23dc03/attachment.html>