Re: Rethinking stable updates policy
John Goerzen wrote:
> Hello,
>
> The Debian stable distribution has been a thorn in our side for a long
> time. We tend to go a long time between releases, which means that
> stable grows less and less useful as time goes on. We also have a
> strict policy on what is allowed into stable.
>
> This policy has many merits, especially for those running Debian on
> production servers. On the other hand, it has many problems. One is
> that current Debian stable can't be installed on many current systems
> due to weak SATA controller support.
>
> I think it's time we reopen the discussion on what stable means and what
> it should mean.
>
> To start with, [1] says that a package is only uploaded to stable when
> it meets one of these criteria:
>
> * it fixes a truly critical functionality problem
>
> * the package becomes uninstallable
>
> * a released architecture lacks the package
>
> I am mainly interested in #1. I think we need to take a more expansive
> view of what constitutes a functionality problem, perhaps replacing
> "truly critical" with "serious".
>
> Examples of things that should happen in stable, but haven't been
> happening reliably:
>
> * Kernel updates with more broad hardware support
This requires new kernel packages, new utilities and a new installer.
It a hell of an effort to get this done. Just look at what it takes
to update these in stable with "only" security updates.
Expecting this to become easier with new kernel versions included is a
little bit off the reality. Feel free to try to get a new kernel via
backports.org and watch how many other packages creep in.
It would be good, though, especially in order to have some support for
hardware that has entered the market after the last Debian release, if
there would be an outside repository for updated kernel and installer
packages. However, nobody considered this important enough yet.
(Hint! Hint!)
> * Infrastructure updates such as ClamAV and Spamassassin
We already have this in form of the volatile archive. That's exactly
what volatile is for and why it has been started. For these packages
it works quite well.
> * Security and other important Firefox updates
I'm sure you only forgot that we do have security updates for Mozilla
and friends (thanks to the great work of Alexander Sack, can't say
that often enough).
Anyway, you want to see new versions, which is fine. However, this
also requires new dependencies since newer versions tend to require
newer libraries. Also there are a lot of translation and plugin
packages that would have to be updated as well - and the software
would behave differently.
That's nothing for a *stable* Debian release. However, thanks to
nobse there is the backports repository which is perfectly suited for
such an effort. Not sure if anybody bothered to backport Mozilla and
friends yet, though. (I guess not. Hint! Hint!)
> Now, we need also to make sure that stable stays stable, and should be
> introducing additional guidelines to accompany this:
>
> * No major architectural changes in packages (don't upgrade
> spamassassin from v2 to v3, but it may be OK to introduce a new
> spamassassin v3 package). Or, no XF86 -> XOrg transition,
> but perhaps a new XF86 point release with more HW support could work
This should not happen *in* the stable distribution since it would
become a floating target instead. The cases you mentioned have
already happened outside of the stable release, i.e. in the backports
archive, iirc.
> * Updates must undergo testing, ideally with peer review
For this we don't have the infrastructure with regards to stable, and
it's also not possible to update stable just again because we noticed
that Firefox creashes 50% of the time. Backports is much easier to
handle for this and should be used.
> * Updates must be drop-in compatible with the released stable --
> no config file incompatibilies or new debconf prompts, no new library
> so versions or deps on libraries not in stable, etc.
This rejects packages like the kernel or Mozilla and friends already.
> It is important to maintain stable as stable for existing server
> installs, but still keep it useful for new deployments. I think we can
> achieve the latter without compromising the former, in a little better
> way that we have done to date.
It's also important for desktop installations that shouldn't change
every other day.
Regards,
Joey
--
Have you ever noticed that "General Public Licence" contains the word "Pub"?
Reply to: