Re: Security support proposed workflow for the very-old-stable (was: Dreamhost dumps Debian)
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)
Reply to: