On Thu, Feb 04, 2016 at 10:18:44AM +0100, Raphael Hertzog wrote: > On Tue, 02 Feb 2016, Niels Thykier wrote: > > > Greg's new policy is to pick the first Linus release in each year for > > > longterm maintenance. The longterm branch for 2016 is based on Linux > > > 4.4, released at the end of week 1 (10th January). By the time stretch > > > is released, 4.4 will be quite old (the same problem squeeze and wheezy > > > had, requiring many driver backports). > > > > Would you prefer that we moved future freezes (i.e. Buster and later), > > so we could always rely on Greg's branch? Not knowing Linux's LTS planning: > > As another data point, I'd like to point out that our freeze/release > schedule also means that we miss most of the benefit from Django's LTS > release. They have an LTS release every two years and they push it out > roughly at the same time than we do with our stable release. > > Maybe it would make sense to have a general policy of aiming to accept > LTS releases during the freeze, or even in the first point update. > We could upload pre-release of upcoming LTS versions before the freeze > (or early in the freeze)... Yet another data point: Ruby makes stable releases every Christmas, what is usually after the freeze; that means that we often release Debian stable with a version of Ruby that was release 2 Christmas ago. e.g. Jessie was released on April 2015 with the stable version of Ruby (2.1) that was released on December 2013. That is not bad per se as by the time we release that stable Ruby version has been very well tested and had already a couple of maintainace releases. But it also means that there is less overlap between our stable maintainance window and the upstream maintainance window for that version. -- Antonio Terceiro <terceiro@debian.org>
Attachment:
signature.asc
Description: PGP signature