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 <hmur...@megapathdsl.net> wrote: > > Kurt's comments look good. This is what I was typing in while that was in > the pipeline. > > fallenpega...@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. > > > >
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
