<div dir="ltr">HI!<div><br></div><div>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.</div><div><br></div><div>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</div><div><br></div><div>..m</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Mar 13, 2016 at 10:51 PM Hal Murray <<a href="mailto:hmurray@megapathdsl.net">hmurray@megapathdsl.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Kurt's comments look good. This is what I was typing in while that was in<br>
the pipeline.<br>
<br>
<a href="mailto:fallenpegasus@gmail.com" target="_blank">fallenpegasus@gmail.com</a> said:<br>
> I propose that we move to a scheduled release model, with the addition of<br>
> security fast releases.<br>
<br>
I think it's more complicated than that.<br>
<br>
There are several tangled ideas. One is release. The other is support.<br>
You haven't said anything about support yet.<br>
<br>
What is the target audience for a release?<br>
How long are we going to support a release?<br>
<br>
I'm assuming support for older releases means apply security fixes. If we<br>
have releases every 2 weeks, that turns into a lot of work. I think that<br>
combination means we only support selected releases. One of the main tasks<br>
of the project manager is to figure out which releases to support.<br>
<br>
You could say the same thing with different words. A release is something<br>
that gets supported. The things that go out every 2 weeks need a different<br>
term, maybe mini-releases or dev-releases.<br>
<br>
If we have supported releases every 6 months or so, I think we should spend a<br>
few weeks before the release concentrating on testing and checking the<br>
documentation.<br>
<br>
<br>
This is handwaving, but I'll start with there being 2 classes of users.<br>
<br>
The first is bleeding edge. Developers can grab the latest from git. In<br>
this context, testers count as developers even if they don't write any code.<br>
Support consists of going forward. Old releases are never fixed. They are<br>
supported only in that you can get them from git to back out of recent<br>
changes if they break something in your environment and/or you are bisecting<br>
a bug.<br>
<br>
The second target is distros. Within a distro, there are probably several<br>
sub-targets. Many distros have 3 "supported" releases. I'll call them<br>
testing, stable, and old.<br>
<br>
The stable release is the one most users are expected to run. The old<br>
release is the previous stable. It stays around to give users plenty of time<br>
to upgrade to the new stable. The testing area is for testing new releases<br>
from upstream and whatever local changes they make.<br>
<br>
Many distros have releases every 6 months to a year.<br>
Ubuntu LTS supports selected releases for 5 years.<br>
<a href="https://wiki.ubuntu.com/LTS" rel="noreferrer" target="_blank">https://wiki.ubuntu.com/LTS</a><br>
RHEL goes out to 10 years.<br>
<a href="https://access.redhat.com/support/policy/updates/errata/" rel="noreferrer" target="_blank">https://access.redhat.com/support/policy/updates/errata/</a><br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
<br>
<br>
--<br>
These are my opinions. I hate spam.<br>
<br>
<br>
<br>
</blockquote></div>