Re: Rethinking stable updates policy
On Sat, Aug 26, 2006 at 08:43:53AM +0200, Martin Schulze wrote:
> John Goerzen wrote:
> > 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.
New kernel packages, and a rebuilt install image, yes. New utilities?
The only one I'm aware of that breaks with newer kernels is udev, and
hasn't that been fixed for awhile now?
I've never had a problem taking a stable box and putting a nice shiny
new kernel on it. Which utilities have to be updated here?
I'm not talking about something like 2.4 to 2.6, just point releases
> 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!)
Well, a repo for updated ISOs would be more useful to people, I
think. But again, when somebody goes to debian.org to download
stable, they'll get something that doesn't work.
It would be better to, say, issue 3.0.1 with a newer kernel package.
This wouldn't even have to cause any impact at all to existing
> > * 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.
True, but it would be better to make it more official. Plus, are you
going to stick X, PostgreSQL, and MySQL in volatile?
> > * 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).
Quite right, sorry.
> Anyway, you want to see new versions, which is fine. However, this
No, that's not a biggie to me.
> > 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.
Not the kernel, which is the most important and most troublesome
piece. That part really needs to be supported directly at debian.org.
> > * 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.
If this stays small-scale -- and it should -- this could be as simple
as having, say, 5 trusted developers' GPG signatures on a message
saying they have evaluated it against standard criteria and it passes.
Doesn't have to be a massive thing.
But you're right, we would absolutely want to make sure we get it
right. It's a hurdle, but I wouldn't call it insurmountable.
> > * 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
Again, I am confused about why this would reject the kernel, since in
my experience, it *is* drop-in compatible.
> > 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.