[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Rethinking stable updates policy


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

 * Infrastructure updates such as ClamAV and Spamassassin

 * Security and other important Firefox updates

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

 * Updates must meet an important userbase need

 * Updates must undergo testing, ideally with peer review

 * 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.

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.

[1] http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-upload-stable

Reply to: