On 08/20/2013 05:17 PM, Clint Byrum wrote: >> E. g: >> - In January 2014 we release Debian 8.0. We make this an LTS release, >> meaning it would get updates for, say 3 years (until January 2017), and >> security updates for 5 years (until January 2019). >> - In February 2015 we release Debian 9.0. Non-LTS release. It will get at >> least 1 year of support (because we won't release the next version until at >> least 1 year later) + 6 months >> - In April 2016 we release Debian 10.0. LTS release. It will get again 3 >> years of updates and 5 years of security updates. This means support for >> Debian 9.0 will end in October 2016 (LTS release date + 6 months) >> - ... >> >> </ideastorm> >> > > All great ideas. I'm more inclined to just suggest that Debian keep > oldstable security patched for an extra year. That is easy for users and > developers to remember, and would give big server users a chance to slow > down the treadmill a little. Of course, it also would put more burden > on DD's.
I thought about having a BoF at Debconf13 about this topic (we talked about it in this list), though there was not enough members of the security team and FTP team so that it would have been productive. So I gave up on the idea. Though I would really like to have a more extended security support, and we can probably discuss this in this list. My initial idea wasn't to never *impose* the extended security maintenance to all DDs. Instead, we could do it on a best-effort basis, collectively. Meaning that anyone willing to do security fixes for the EOL distribution (one year after stable is released) could do so through a special repository. Nobody would be forced to maintain its own packages, but at the same time, anyone could help on any package. Also, we wouldn't have to tell that we maintain *all* packages, but probably a subset of things we declare important (simply based on what we collectively decide to work on). This effort could be done experimentally to start with, through a non-official debian.net repository, when Squeeze will be EOL. Then if it works well for the next 2 years after Squeeze is EOL, then probably we can make it a bit more official. I don't think it is realistic to try to do anything else. We simply don't have enough man power to do so. Remember that in Ubuntu, the role of the security team is a lot different than what the Debian security team does. In Debian, the security team is there to mainly do communication, and peer-review the updated packages. In Ubuntu, the security team is composed of Canonical *employees*, that actually do the work of backporting patches. We can't reasonably expect that any given package maintainer in Debian will backport patches for old-stable AND very-old-stable. I don't think it's reasonable also to impose more work to the FTP masters, the security team, etc. if we don't just try, and see if it is doable. Though I have no idea how to duplicate a dak setup and probably will not have the time to investigate how to do it myself, it could be done through a more light infrastructure (which I can host if we don't find anything better). Thoughts anyone? Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5213c4a0.9000...@debian.org
