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?
Which 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
within 2.6.
> 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
installations.
> > * 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
> already.
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.
Indeed.
-- John
Reply to: