Re: Rethinking stable updates policy
On Tue, Aug 29, 2006 at 10:52:15PM +0200, Moritz Muehlenhoff wrote: > David Nusinow wrote: > >> The rough plan is to provide an alternative set of updated kernel packages > >> and potentially also xservers (depending on how modular the new X.org > >> modulization really is) nine months after Etch release. ian.org > >> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > > This may be problematic. The server's ABI version will change, requiring > > the old drivers to be rebuilt or new drivers. This may or may not happen > > every upstream X.org release, I can't really say without more experience, > > but the ABI did break between 7.0 and 7.1. > > > > The server should work fine without too many additional backports of the > > libs or protocol headers though. The 7.1 server only requires an update of > > one lib and two protocol headers from 7.0. I'd imagine that this will be > > more or less the average. > > I hope you or someone else from the XSF joins this effort in 2007, but let's > rest it until Etch is released. I don't run stable myself right now, but if no one else from the XSF is interested I'd be happy to devote some time to helping out in the future. Ping debian-x once Etch is out and we'll figure it out. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Rethinking stable updates policy
David Nusinow wrote: >> The rough plan is to provide an alternative set of updated kernel packages >> and potentially also xservers (depending on how modular the new X.org >> modulization really is) nine months after Etch release. ian.org >> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > This may be problematic. The server's ABI version will change, requiring > the old drivers to be rebuilt or new drivers. This may or may not happen > every upstream X.org release, I can't really say without more experience, > but the ABI did break between 7.0 and 7.1. > > The server should work fine without too many additional backports of the > libs or protocol headers though. The 7.1 server only requires an update of > one lib and two protocol headers from 7.0. I'd imagine that this will be > more or less the average. I hope you or someone else from the XSF joins this effort in 2007, but let's rest it until Etch is released. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Rethinking stable updates policy
David Nusinow wrote: > On Sun, Aug 27, 2006 at 10:57:45PM +0200, Moritz Muehlenhoff wrote: > > The rough plan is to provide an alternative set of updated kernel packages > > and potentially also xservers (depending on how modular the new X.org > > modulization really is) nine months after Etch release. ian.org > > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > This may be problematic. The server's ABI version will change, requiring > the old drivers to be rebuilt or new drivers. This may or may not happen > every upstream X.org release, I can't really say without more experience, > but the ABI did break between 7.0 and 7.1. In theory this shouldn't be too much of a problem since the new alternative repository would "only" grow bigger by forward ports of those drivers as well. In theory... Regards, Joey -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Rethinking stable updates policy
Moritz Muehlenhoff wrote: > Martin Schulze wrote: > > 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!) > > Not quite: Some people met at Debconf (including Frans, aba, Dann and me) > to discuss a potential solution to the hardware problem. Dann sent a report > around, didn't you get it? I don't know. I have to admit that I have very bad memory and forget a lot of things. Even if I should have replied to it, that doesn't mean I'd remember it. So... Dunno... > The rough plan is to provide an alternative set of updated kernel packages > and potentially also xservers (depending on how modular the new X.org > modulization really is) nine months after Etch release. Everyone who has Oh, that one. I've heard about it before. I consider it a good idea. > installed regular Etch would stay with it and those requiring it could > choose it instead (possibly through an etch-update apt source). However > all fine details need to be sorted out and for now the priority should be > to release Etch on the 4th of December. Ack. Regards, Joey -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Rethinking stable updates policy
On Mon, Aug 28, 2006 at 10:11:06PM +, David Nusinow wrote: > libs or protocol headers though. The 7.1 server only requires an update of > one lib and two protocol headers from 7.0. I'd imagine that this will be ^^^ Sorry, two libs, although one is mesa. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Rethinking stable updates policy
On Sun, Aug 27, 2006 at 10:57:45PM +0200, Moritz Muehlenhoff wrote: > The rough plan is to provide an alternative set of updated kernel packages > and potentially also xservers (depending on how modular the new X.org > modulization really is) nine months after Etch release. ian.org > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] This may be problematic. The server's ABI version will change, requiring the old drivers to be rebuilt or new drivers. This may or may not happen every upstream X.org release, I can't really say without more experience, but the ABI did break between 7.0 and 7.1. The server should work fine without too many additional backports of the libs or protocol headers though. The 7.1 server only requires an update of one lib and two protocol headers from 7.0. I'd imagine that this will be more or less the average. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Rethinking stable updates policy
Martin Schulze wrote: > 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!) Not quite: Some people met at Debconf (including Frans, aba, Dann and me) to discuss a potential solution to the hardware problem. Dann sent a report around, didn't you get it? The rough plan is to provide an alternative set of updated kernel packages and potentially also xservers (depending on how modular the new X.org modulization really is) nine months after Etch release. Everyone who has installed regular Etch would stay with it and those requiring it could choose it instead (possibly through an etch-update apt source). However all fine details need to be sorted out and for now the priority should be to release Etch on the 4th of December. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Rethinking stable updates policy
On Sun, Aug 27, 2006 at 08:48:03PM +0200, Martin Schulze wrote: > and used Debian packaging, here's what was required only to get the > binary package installed: > > http://www.backports.org sarge-backports/main module-init-tools 3.2.2-2bpo1 > [79.3kB] > http://www.backports.org sarge-backports/main makedev 2.3.1-81bpo1 [42.0kB] > http://www.backports.org sarge-backports/main libklibc 1.4.11-2bpo1 [41.1kB] > http://www.backports.org sarge-backports/main klibc-utils 1.4.11-2bpo1 [144kB] > http://www.backports.org sarge-backports/main libvolume-id0 0.093-0bpo1 > [56.6kB] > http://www.backports.org sarge-backports/main udev 0.093-0bpo1 [253kB] > http://www.backports.org sarge-backports/main initramfs-tools 0.75~bpo.1 > [52.9kB] > > So it's not only the kernel but half a dozen more packages. Even more > are required if you want to be able to compile the kernel package as > well. Even so (why is a new makedev required, for instance?), this is still not all that bad. Most of these are single-purpose tools -- in fact, all of them except for udev are. I think the cost of having to update 7 small packages in stable is small compared to the cost of being uninstallable on modern hardware. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Rethinking stable updates policy
On Sun, Aug 27, 2006 at 08:48:03PM +0200, Martin Schulze wrote: > Martin Schulze 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. > > Since I've had to update the kernel on a machine to a more recent one > and used Debian packaging, here's what was required only to get the > binary package installed: > > http://www.backports.org sarge-backports/main module-init-tools 3.2.2-2bpo1 > [79.3kB] > http://www.backports.org sarge-backports/main makedev 2.3.1-81bpo1 [42.0kB] > http://www.backports.org sarge-backports/main libklibc 1.4.11-2bpo1 [41.1kB] > http://www.backports.org sarge-backports/main klibc-utils 1.4.11-2bpo1 [144kB] > http://www.backports.org sarge-backports/main libvolume-id0 0.093-0bpo1 > [56.6kB] > http://www.backports.org sarge-backports/main udev 0.093-0bpo1 [253kB] > http://www.backports.org sarge-backports/main initramfs-tools 0.75~bpo.1 > [52.9kB] > > So it's not only the kernel but half a dozen more packages. Even more > are required if you want to be able to compile the kernel package as > well. As said, most of those are pulled in by initramfs-tools, yaird is much more economic in this aspect, and why it has my original vote for default ramdisk generator tool in debian. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Rethinking stable updates policy
Martin Schulze 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. Since I've had to update the kernel on a machine to a more recent one and used Debian packaging, here's what was required only to get the binary package installed: http://www.backports.org sarge-backports/main module-init-tools 3.2.2-2bpo1 [79.3kB] http://www.backports.org sarge-backports/main makedev 2.3.1-81bpo1 [42.0kB] http://www.backports.org sarge-backports/main libklibc 1.4.11-2bpo1 [41.1kB] http://www.backports.org sarge-backports/main klibc-utils 1.4.11-2bpo1 [144kB] http://www.backports.org sarge-backports/main libvolume-id0 0.093-0bpo1 [56.6kB] http://www.backports.org sarge-backports/main udev 0.093-0bpo1 [253kB] http://www.backports.org sarge-backports/main initramfs-tools 0.75~bpo.1 [52.9kB] So it's not only the kernel but half a dozen more packages. Even more are required if you want to be able to compile the kernel package as well. Regards, Joey -- In the beginning was the word, and the word was content-type: text/plain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Rethinking stable updates policy
John Goerzen wrote: > But I'm not trying to talk in this thread about how hard or easy it is > technically to build stuff for stable. That level will change over > time. (And if we really find it so much more difficult to build a > kernel for stable than other distros do, we need to examine that and > make needed improvements. Maybe Joey Hess can comment on the > installer here.) > > The question I'm trying to open up is first: > > Is it useful to update a kernel in stable? It is probably useful to provide updated kernel pacakges and installer - but separate from Debian stable. > And secondly: > > Is it possible to do it in a sane way, preserving stability? Good question. For sarge and >= 2.6.15 I'd say no. > And finally, if so, then we need to ask: > > How can we make it easy for everyone involved to do this? Don't change the kernel too much, don't change kernel packaging too much. While we have influence on the second, we don't have influence on the first. Regards, Joey -- Have you ever noticed that "General Public Licence" contains the word "Pub"? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Rethinking stable updates policy
On Sat, Aug 26, 2006 at 09:03:12PM +0900, Kenshi Muto wrote: > At Sat, 26 Aug 2006 11:52:29 +0200, > Michael Banck wrote: > > On Sat, Aug 26, 2006 at 08:43:53AM +0200, Martin Schulze wrote: > > > 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!) > > > > Kenshi MUTO provides some at http://kmuto.jp/debian/d-i/ > > And when you see my SVN repository and sources, > you'll find how hard to use newer Debian kernel on current > Sarge installer, John. > > If new kernel has perfect compatibilities with older kernel > (such as using devfs and mkinitrd), updates may be easier. > Even if so, I think applying new kernel will make a lot of > jobs for d-i team. Again, maybe I'm missing something on mkinitrd, but I don't see that as such an issue. devfs, I can see that. But I'm not trying to talk in this thread about how hard or easy it is technically to build stuff for stable. That level will change over time. (And if we really find it so much more difficult to build a kernel for stable than other distros do, we need to examine that and make needed improvements. Maybe Joey Hess can comment on the installer here.) The question I'm trying to open up is first: Is it useful to update a kernel in stable? And secondly: Is it possible to do it in a sane way, preserving stability? And finally, if so, then we need to ask: How can we make it easy for everyone involved to do this? -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Rethinking stable updates policy
At Sat, 26 Aug 2006 11:52:29 +0200, Michael Banck wrote: > On Sat, Aug 26, 2006 at 08:43:53AM +0200, Martin Schulze wrote: > > 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!) > > Kenshi MUTO provides some at http://kmuto.jp/debian/d-i/ And when you see my SVN repository and sources, you'll find how hard to use newer Debian kernel on current Sarge installer, John. If new kernel has perfect compatibilities with older kernel (such as using devfs and mkinitrd), updates may be easier. Even if so, I think applying new kernel will make a lot of jobs for d-i team. Thanks, -- Kenshi Muto [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Rethinking stable updates policy
On Sat, Aug 26, 2006 at 08:43:53AM +0200, Martin Schulze wrote: > 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!) Kenshi MUTO provides some at http://kmuto.jp/debian/d-i/ cheers, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Rethinking stable updates policy
[EMAIL PROTECTED] wrote: >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". I fully agree. I do not consider "volatile" a solution. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Rethinking stable updates policy
Sven Luther wrote: > > mkinitrd > > mkinitrd is dead :) Whatever... :) > > debhelper > > debhelper ??? Didn't it creep in? Maybe not. > > yard > > yaird is its name. Oh well... > > Just try to get a more recent kernel from backports.org on a sarge > > machine and you'll see. > > Actually, apart from the udev issue, only a recompiled yaird is needed to run > the latest sid kernel on a sarge machine. Err... you'll have to be able to compile the kernel as well or you won't be able to add security support to it, and that would be an even larger nightmare. > Naturally, initramfs-tools and is huge dependency chain on world+dog is a > fully other matter. Ah, maybe I meant this one instead of mkinitrd :) Regards, Joey -- Have you ever noticed that "General Public Licence" contains the word "Pub"? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Rethinking stable updates policy
On Sat, Aug 26, 2006 at 09:57:37AM +0200, Martin Schulze wrote: > John Goerzen wrote: > > 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? > > I already forgot most of them again, but among the packages required were: > > mkinitrd mkinitrd is dead :) > kernel-package well, one could consider kernel-package as part of the kernel package, really. > debhelper debhelper ??? > yard yaird is its name. > Just try to get a more recent kernel from backports.org on a sarge > machine and you'll see. Actually, apart from the udev issue, only a recompiled yaird is needed to run the latest sid kernel on a sarge machine. I am actually typing this, on a sarge/powerpc machine, where the latest sid kernels was installed as is on a sarge system with only the rebuild yaird. Naturally, initramfs-tools and is huge dependency chain on world+dog is a fully other matter. > > The only one I'm aware of that breaks with newer kernels is udev, and > > hasn't that been fixed for awhile now? > > Oh, right. udev as well. I prayed for the machine to boot as it was > in a data center several km away from me. *sweat* Yes, we should get a backported udev with more stability going or something. Udev is the real pain on this, and since initramfs-tools needs it ... > > I'm not talking about something like 2.4 to 2.6, just point releases > > within 2.6. > > I'm talking about 2.6.8 (sarge) to 2.6.15 (current kernel that time) yeah, udev sucks, but apart from that it should be transparent. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Rethinking stable updates policy
John Goerzen wrote: > 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? I already forgot most of them again, but among the packages required were: mkinitrd kernel-package debhelper yard Just try to get a more recent kernel from backports.org on a sarge machine and you'll see. > The only one I'm aware of that breaks with newer kernels is udev, and > hasn't that been fixed for awhile now? Oh, right. udev as well. I prayed for the machine to boot as it was in a data center several km away from me. *sweat* > I'm not talking about something like 2.4 to 2.6, just point releases > within 2.6. I'm talking about 2.6.8 (sarge) to 2.6.15 (current kernel that time) > > 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. That's something that could be done afterwards, but I agree, that updated iso images, at least for the businesscard and network installation would be great as well. > 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. As I told you already, just look at the progress to get an updated 2.6.8 inclusive installer into the 3.1 stable release. It's problematic enough already, not to speak about a new kernel version and new tools and modified installer code, and differntly behaving packages, and and and. > > > * 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? No, but into backports.org. We're trying to get volatile more official, to be continued... > > > * 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. That's not sufficient when new versions of software are included that behave different, hence, break scripts, break users impression and the like. That will make Debian stable an unstable system. This is not what we should aim at. Really. > 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. Such updates should be provided as an add-on like with the backports.org archive. Then users can decide if they want to try an update and maybe become happy with it. By the way, I've been told that a more recent Firefox is already included in the backports archive. Feel free to use it. > > > * 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. Well... not at all. It may require a more recent udev, more recent hotplug, more recent mkinitrd, more recent $foo, old drivers that formerly worked, may not work anymore, old firmware (sorry, binary-only, non-free crap) that was used formerly may not work anymore since a newer version may be required. Devices may be named differntly even without udev (think of two SCSI adapter whose order is switched for whatever reason, this has happened already). Regards, Joey -- Have you ever noticed that "General Public Licence" contains the word "Pub"? -- To UNSUBSCRI
Re: Rethinking stable updates policy
On Sat, Aug 26, 2006 at 02:13:33AM -0500, John Goerzen wrote: > 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. Well, the etch preparation time saw the switch to 2.6, the devfs removal and the corresponding ramdisk generator troubles, as well as assorted udev troubles. The real problem, is that for seamless kernel upgrades, a lot of infrastructure is needed, and this has been part of my plan (or private agenda like Frans accused me of, altough there is nothing private about it, since i claimed it high and strong since over a year now, and it is done not to further my own benefit, but for the best of debian, the ease of the stable security team and stable d-i upgrades, and situation likes this. Anyway, the plan i was proposing since april 2005, shortly before the etch release, called for an unified kernel package (which we attained in a successfull way, culminating with the 2.6.14 release and its same-day upload), as well as other yet to be implemented or currently under implementation parts. It had : - a single kernel source package, building all the .debs for all arches, as well as all the .udebs for d-i. - an infrastructure for out of tree modules, either incorporating them in the same main kernel package like ubuntu has done, or a single out-of-tree package like is under way, or a set of individual such out of tree packages, but identified ones, and all using the same infrastructure. It was trying to push for this one, which would make upgrading kernels on kernel abi changes for security or upgrade issues seamless, but faced the very strong and agressive oposition of the d-i team, who is now in a situation where any changes in this respect cannot be accepted by them, for fear of losing face and having to admit that i was right, so we are thus hosed in the near future. This plan needs to be complemented by cooperation with the other kernel related tools, like udev, module-init-tools and such. With all this in place, we could do kernel and d-i upgrades in a matter of days, and it only would need tests for regressions in the kernel code itself, or in the interface of those helper tools, but given the importance of those kernels upgrades (a quick test, who really runs sarge kernels on sarge, and not some self-built or backported ones ?), it would be fairly easy to find a big enough tester set to validate those for later upgrades. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Rethinking stable updates policy
Martin Schulze schrieb am Samstag, den 26. August 2006: *snip* > 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!) Hey, thats already there: http://backports.org/debian/pool/main/f/firefox/ http://backports.org/debian/pool/main/t/thunderbird/ But please read the instructions before: http://backports.org/dokuwiki/doku.php?id=instructions Alex signature.asc Description: Digital signature
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Rethinking stable updates policy
Marc Haber wrote: > > 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 would love to have "the new package for stable eases future update" > as this would allow to fix stable issues which would otherwise cause > future grief to fix. For example, a more allowing policy would allow > exim 3 to warn against new installations and in turn motivate people > to update to exim3 before they take the etch plunge. Adding a warning *now* does not imply to *eases future update*. Regards, Joey -- Have you ever noticed that "General Public Licence" contains the word "Pub"? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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"? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Rethinking stable updates policy
Il giorno ven, 25/08/2006 alle 16.45 -0500, John Goerzen ha scritto: > * Updates must undergo testing, ideally with peer review This could be impossible if stable and testing distributions are binary-incompatible (ie. using different versions of glibc), just like sarge and etch are in this moment. Anyway, I mostly agree with your proposal, even if some of the points you raised can be achieved using volatile. -- Fabio Tranchitella <[EMAIL PROTECTED]>.''`. Proud Debian GNU/Linux developer, admin and user.: :' : `. `'` http://people.debian.org/~kobold/ `- _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 signature.asc Description: Questa รจ una parte del messaggio firmata digitalmente
Re: Rethinking stable updates policy
On Fri, Aug 25, 2006 at 04:45:31PM -0500, John Goerzen wrote: > 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 would love to have "the new package for stable eases future update" as this would allow to fix stable issues which would otherwise cause future grief to fix. For example, a more allowing policy would allow exim 3 to warn against new installations and in turn motivate people to update to exim3 before they take the etch plunge. > 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 I think we have volatile for this, allowing people to choose whether they need absolute stability or new infrastructure. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Rethinking stable updates policy
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 * 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
