Re: renaming linux-kernel source package
On Tue, Jul 12, 2005 at 09:47:49AM +0300, dann frazier wrote: On Tue, 2005-07-12 at 04:49 +0200, Goswin von Brederlow wrote: dann frazier [EMAIL PROTECTED] writes: Note that one side-effect of dropping the minor number in the source package name is that we won't be able to have one kernel in sid and one in testing and be able to use sid as an update path. For example, consider the way we had 2.6.10 in sid and 2.6.8 in testing late in sarge. This allowed us to get some testing on a kernel and make a more informed decision about which one we froze on for sarge. We can of course use experimental for this, but we can't expect to get much testing w/ experimental. Why not? Both testing and sid can have different versions of kernel-source-2.6 without problems. One just havs to report a RC bug against kernel-source-2.6 in sid to prevent it entering testing. As a hypothetical example, say linux-2.6 (2.6.12-X) is in testing, and its currently what we plan to ship in the next release. 2.6.14 is the latest upstream. What should we keep in sid? If it is late in the release process, we use testing-proposed-updates for 2.6.12 uploads. That is what it is for, and i suppose it is now finally fixed. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: renaming linux-kernel source package
dann frazier writes... Note that one side-effect of dropping the minor number in the source package name is that we won't be able to have one kernel in sid and one in testing and be able to use sid as an update path. Did you mean will instead of won't above? -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: renaming linux-kernel source package
On Tue, 2005-07-12 at 04:49 +0200, Goswin von Brederlow wrote: dann frazier [EMAIL PROTECTED] writes: Note that one side-effect of dropping the minor number in the source package name is that we won't be able to have one kernel in sid and one in testing and be able to use sid as an update path. For example, consider the way we had 2.6.10 in sid and 2.6.8 in testing late in sarge. This allowed us to get some testing on a kernel and make a more informed decision about which one we froze on for sarge. We can of course use experimental for this, but we can't expect to get much testing w/ experimental. Why not? Both testing and sid can have different versions of kernel-source-2.6 without problems. One just havs to report a RC bug against kernel-source-2.6 in sid to prevent it entering testing. As a hypothetical example, say linux-2.6 (2.6.12-X) is in testing, and its currently what we plan to ship in the next release. 2.6.14 is the latest upstream. What should we keep in sid? If we only upload new 2.6.12's into sid, we can let new releases flow into testing, but we don't get 2.6.14 tested in sid. This prevents us from making a well informed decision if we should want to consider switching to 2.6.14 in testing, since we don't gain the testing of sid users. If we go ahead and upload 2.6.14 to sid, then we can't use sid-testing as a way to get new 2.6.12's into testing. This example isn't so hypothetical - during sarge preparation, we'd chosen 2.6.8 but were able to consider 2.6.10 later because it had been maintained in sid. -- dann frazier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: renaming linux-kernel source package
GOTO Masanori writes... At Mon, 11 Jul 2005 02:08:51 +0300, Andres Salomon wrote: This is the source package only, not the binary (image) package; so, if users have a working kernel installed, they will be able to upgrade, test out the new kernel, and use the old one if the new one is broken. If we upload a new kernel that is broken, and it replaces the old one, it will still only be in unstable (as long as someone files an RC bug. Experience has shown that people are not shy about filing RC bugs when we break their machine horribly ;) Thanks for your explanation, I was confused the difference between source package and binary package. Yes, your idea is definitely good idea for me. I still see the issue that GOTO brought up as a problem. There is no one size fits all 2.6 kernel version, there's just too many drivers and too many changes. I don't think users should be expected to rely on a binary kernel-image only available if they've already installed it(or have to get it from snapshot.debian.net). What about a user who relies on an older binary kernel-image and loses a hard drive and wants to reinstall? Or someone with a bunch of particular identical systems that need a non-latest kernel? For example I have a PC that uses an SiS chipset that doesn't work at all with the 2.6.8 kernel in sarge due to it's sucky USB stack. I really like the proposal other than that, but is there a way to keep a limited set of older stuff around longer? Sort of analogous to the oldlibs idea. Maybe the package can split off older versions of itself, with more descriptive names, as it moves forward. Or something like that... -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: renaming linux-kernel source package
Matt Taggart [EMAIL PROTECTED] writes: I really like the proposal other than that, but is there a way to keep a limited set of older stuff around longer? Sort of analogous to the oldlibs idea. Maybe the package can split off older versions of itself, with more descriptive names, as it moves forward. Or something like that... snapshot.d.n? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: renaming linux-kernel source package
Goswin von Brederlow writes... Matt Taggart [EMAIL PROTECTED] writes: I really like the proposal other than that, but is there a way to keep a limited set of older stuff around longer? Sort of analogous to the oldlibs idea. Maybe the package can split off older versions of itself, with more descriptive names, as it moves forward. Or something like that... snapshot.d.n? You didn't read the part of my message where I said that snapshot.d.n wasn't acceptable. Of course this is just my opinion. Maybe if snapshot was an official debian.org service and publicly mirrored it might be ok? -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: renaming linux-kernel source package
On Mon, 2005-07-11 at 01:53 -0700, Matt Taggart wrote: GOTO Masanori writes... At Mon, 11 Jul 2005 02:08:51 +0300, Andres Salomon wrote: This is the source package only, not the binary (image) package; so, if users have a working kernel installed, they will be able to upgrade, test out the new kernel, and use the old one if the new one is broken. If we upload a new kernel that is broken, and it replaces the old one, it will still only be in unstable (as long as someone files an RC bug. Experience has shown that people are not shy about filing RC bugs when we break their machine horribly ;) Thanks for your explanation, I was confused the difference between source package and binary package. Yes, your idea is definitely good idea for me. I still see the issue that GOTO brought up as a problem. There is no one size fits all 2.6 kernel version, there's just too many drivers and too many changes. I don't think users should be expected to rely on a binary kernel-image only available if they've already installed it(or have to get it from snapshot.debian.net). What about a user who relies on an older binary kernel-image and loses a hard drive and wants to reinstall? Or someone with a bunch of particular identical systems that need a non-latest kernel? For example I have a PC that uses an SiS chipset that doesn't work at all with the 2.6.8 kernel in sarge due to it's sucky USB stack. One of the things I like about sarge is the ability to install 2.4 or 2.6 kernels. I prefer the new kernel development model, but this does mean that we're only going to have a 2.6 kernel. This is fine when everything works, but when there's breakage within a specific driver, it's invaluable (especially during install) to be able to fall back to an older kernel. This is something we should probably discuss with the security team. On one hand, it would be useful to have an older kernel to fall back on. On the other, it's almost twice as much work work to maintain security fixes for an older kernel. I really like the proposal other than that, but is there a way to keep a limited set of older stuff around longer? Sort of analogous to the oldlibs idea. Maybe the package can split off older versions of itself, with more descriptive names, as it moves forward. Or something like that... Thiemo's concerns lead me to believe that perhaps we should track two kernels at all times, assuming the security team agrees. The two source packages could be called linux-2.6 and linux-2.6-new, where linux-2.6 might contain 2.6.12 images, built for all architectures, and linux-2.6-new might contain 2.6.14 images that we're currently attempting to build for all archs. While 2.6.14 is the latest and greatest from upstream, we could try to get it in a state that's preferrable for all archs; if we achieve that, update linux-2.6 to use 2.6.14. If 2.6.15 comes out in the meantime, then release linux-2.6-new with that, and attempt to get all archs happy with that kernel. This is a similar strategy to testing, except instead of things happening automatically, we're trying to manually control it. Keeping a space of several versions between linux-2.6 and linux-2.6-new will mean that when it comes time to release etch, users will hopefully have the ability to select between two significantly different kernels during install. -- Andres Salomon [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: renaming linux-kernel source package
dann frazier [EMAIL PROTECTED] writes: On Mon, 2005-07-11 at 01:53 -0700, Matt Taggart wrote: GOTO Masanori writes... At Mon, 11 Jul 2005 02:08:51 +0300, Andres Salomon wrote: This is the source package only, not the binary (image) package; so, if users have a working kernel installed, they will be able to upgrade, test out the new kernel, and use the old one if the new one is broken. If we upload a new kernel that is broken, and it replaces the old one, it will still only be in unstable (as long as someone files an RC bug. Experience has shown that people are not shy about filing RC bugs when we break their machine horribly ;) Thanks for your explanation, I was confused the difference between source package and binary package. Yes, your idea is definitely good idea for me. I still see the issue that GOTO brought up as a problem. There is no one size fits all 2.6 kernel version, there's just too many drivers and too many changes. We are at least pretending that's the case, because we do not plan to ever have multiple 2.6 kernels in a single stable release. If there's a bug in the kernel we're currently trying to stablize, then it needs to be fixed in that version. Note that one side-effect of dropping the minor number in the source package name is that we won't be able to have one kernel in sid and one in testing and be able to use sid as an update path. For example, consider the way we had 2.6.10 in sid and 2.6.8 in testing late in sarge. This allowed us to get some testing on a kernel and make a more informed decision about which one we froze on for sarge. We can of course use experimental for this, but we can't expect to get much testing w/ experimental. Why not? Both testing and sid can have different versions of kernel-source-2.6 without problems. One just havs to report a RC bug against kernel-source-2.6 in sid to prevent it entering testing. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: renaming linux-kernel source package
Andres Salomon wrote: Hi, I'm going to suggest renaming our 2.6.12 source package from linux-kernel-2.6.12 to linux-kernel-2.6. Thoughts? Dann Frazier and I have discussed this on IRC a little bit, and come up w/ the following points.. * Source: linux-kernel-2.6, Version: 2.6.12-1 * As long as each arch is in synch, there are no GPL issues with older binary packages being in the archive w/out the source. * Nicer for bugs; http://packages.qa.debian.org/l/linux-kernel-2.6.html gets us all bugs for 2.6.12+ kernels, versus having to look at linux-kernel-2.6.12.html, linux-kernel-2.6.13.html, etc. * Older kernels get removed; no need to ask for manual removal of linux-kernel-2.6.12 after 2.6.13 becomes available for all archs. However, we lose the ability to have multiple 2.6's in a release, which sounds like a win to me; we shouldn't be doing multiple 2.6 releases anymore anyways, the security team has made it clear they don't want to support multiple kernels, and it would be extra pressure for all archs to keep up. This makes it unlikely to ever get working mips/mipsel kernels in the single source package. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: renaming linux-kernel source package
On Mon, 2005-07-11 at 04:00 +0900, GOTO Masanori wrote: At Sun, 10 Jul 2005 16:48:15 +0200, maximilian attems wrote: * Older kernels get removed; no need to ask for manual removal of linux-kernel-2.6.12 after 2.6.13 becomes available for all archs. However, we lose the ability to have multiple 2.6's in a release, which sounds like a win to me; we shouldn't be doing multiple 2.6 releases anymore anyways, the security team has made it clear they don't want to support multiple kernels, and it would be extra pressure for all archs to keep up. One concern is broken kernels; old working kernel is removed due to new kernel version is installed, but new one does work. It may be kernel crash (ex: oops during bootup), or some module breakage (ex: sound module cannot resolve its symbols correctly). In other words, I (and I guess a lot of people) have been used between working or non-working kernels via kernel package version number. Except for this worry, it's nice idea. This is the source package only, not the binary (image) package; so, if users have a working kernel installed, they will be able to upgrade, test out the new kernel, and use the old one if the new one is broken. If we upload a new kernel that is broken, and it replaces the old one, it will still only be in unstable (as long as someone files an RC bug. Experience has shown that people are not shy about filing RC bugs when we break their machine horribly ;) I think asking to debian-devel and so on is generally good idea to hear thoughts of user/developer. This shouldn't affect users, only developers. there is still snapshot.d.o for unhappy testers. Note that recently snapshot.d.o got fs crash; it's still under fsck recovery. snapshot.d.o is not perfect solutions for such users... Regards, -- gotom -- Andres Salomon [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: renaming linux-kernel source package
On Mon, 11 Jul 2005 00:11:49 +0200, Thiemo Seufer wrote: Andres Salomon wrote: Hi, I'm going to suggest renaming our 2.6.12 source package from linux-kernel-2.6.12 to linux-kernel-2.6. Thoughts? Dann Frazier and I have discussed this on IRC a little bit, and come up w/ the following points.. * Source: linux-kernel-2.6, Version: 2.6.12-1 * As long as each arch is in synch, there are no GPL issues with older binary packages being in the archive w/out the source. * Nicer for bugs; http://packages.qa.debian.org/l/linux-kernel-2.6.html gets us all bugs for 2.6.12+ kernels, versus having to look at linux-kernel-2.6.12.html, linux-kernel-2.6.13.html, etc. * Older kernels get removed; no need to ask for manual removal of linux-kernel-2.6.12 after 2.6.13 becomes available for all archs. However, we lose the ability to have multiple 2.6's in a release, which sounds like a win to me; we shouldn't be doing multiple 2.6 releases anymore anyways, the security team has made it clear they don't want to support multiple kernels, and it would be extra pressure for all archs to keep up. This makes it unlikely to ever get working mips/mipsel kernels in the single source package. Perhaps you could give a reason why this is the case? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: renaming linux-kernel source package
Andres Salomon wrote: On Mon, 11 Jul 2005 00:11:49 +0200, Thiemo Seufer wrote: Andres Salomon wrote: Hi, I'm going to suggest renaming our 2.6.12 source package from linux-kernel-2.6.12 to linux-kernel-2.6. Thoughts? Dann Frazier and I have discussed this on IRC a little bit, and come up w/ the following points.. * Source: linux-kernel-2.6, Version: 2.6.12-1 * As long as each arch is in synch, there are no GPL issues with older binary packages being in the archive w/out the source. * Nicer for bugs; http://packages.qa.debian.org/l/linux-kernel-2.6.html gets us all bugs for 2.6.12+ kernels, versus having to look at linux-kernel-2.6.12.html, linux-kernel-2.6.13.html, etc. * Older kernels get removed; no need to ask for manual removal of linux-kernel-2.6.12 after 2.6.13 becomes available for all archs. However, we lose the ability to have multiple 2.6's in a release, which sounds like a win to me; we shouldn't be doing multiple 2.6 releases anymore anyways, the security team has made it clear they don't want to support multiple kernels, and it would be extra pressure for all archs to keep up. This makes it unlikely to ever get working mips/mipsel kernels in the single source package. Perhaps you could give a reason why this is the case? Because I'm currently at 2.5 of ~8 subarchitectures working for 2.6.12, and I hear already talk about 2.6.13. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: renaming linux-kernel source package
On Sun, 10 Jul 2005 19:46:46 +0200, Bastian Blank wrote: On Sun, Jul 10, 2005 at 04:40:04PM +0300, Andres Salomon wrote: * Older kernels get removed; no need to ask for manual removal of linux-kernel-2.6.12 after 2.6.13 becomes available for all archs. However, we lose the ability to have multiple 2.6's in a release, which sounds like a win to me; we shouldn't be doing multiple 2.6 releases anymore anyways, the security team has made it clear they don't want to support multiple kernels, and it would be extra pressure for all archs to keep up. And we can't upload a new kernel until it builds on any arch. Do you realy want to force some arches out of the subproject? Not at all; we won't be able to get a kernel into testing until it builds on all archs. We'll be able to upload a new kernel at any time; it may FTBFS on s390, at which point someone will have to fix it. Note that this is the case with single-source packaging anyways; this just makes it so that we won't keep around older kernels just because they support a certain architecture. Also note that (at the request of svenl), the new packaging supports subarchs; that is, patches to the main kernel source that don't get applied on every architecture. I still have reservations about people abusing this, but it should allow for architectures with huge patches against mainline (ie, mips' 2MB 2.6.12 diff that ths pointed me at) to be able to keep up-to-date without negatively affecting the other archs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: renaming linux-kernel source package
On Mon, 11 Jul 2005 01:44:56 +0200, Thiemo Seufer wrote: Andres Salomon wrote: On Mon, 11 Jul 2005 00:11:49 +0200, Thiemo Seufer wrote: Andres Salomon wrote: Hi, I'm going to suggest renaming our 2.6.12 source package from linux-kernel-2.6.12 to linux-kernel-2.6. Thoughts? Dann Frazier and I have discussed this on IRC a little bit, and come up w/ the following points.. * Source: linux-kernel-2.6, Version: 2.6.12-1 * As long as each arch is in synch, there are no GPL issues with older binary packages being in the archive w/out the source. * Nicer for bugs; http://packages.qa.debian.org/l/linux-kernel-2.6.html gets us all bugs for 2.6.12+ kernels, versus having to look at linux-kernel-2.6.12.html, linux-kernel-2.6.13.html, etc. * Older kernels get removed; no need to ask for manual removal of linux-kernel-2.6.12 after 2.6.13 becomes available for all archs. However, we lose the ability to have multiple 2.6's in a release, which sounds like a win to me; we shouldn't be doing multiple 2.6 releases anymore anyways, the security team has made it clear they don't want to support multiple kernels, and it would be extra pressure for all archs to keep up. This makes it unlikely to ever get working mips/mipsel kernels in the single source package. Perhaps you could give a reason why this is the case? Because I'm currently at 2.5 of ~8 subarchitectures working for 2.6.12, and I hear already talk about 2.6.13. I wasn't aware that you worked on mips/mipsel stuff for older kernels in the archive anyways, except for the case when we decide to stabilize on a certain version for a release. In any case, now that experimental is autobuilt, we can upload a new kernel to it and stabilize architectures, while simultaneously updating the older version in sid -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: renaming linux-kernel source package
Andres Salomon wrote: [snip] * Older kernels get removed; no need to ask for manual removal of linux-kernel-2.6.12 after 2.6.13 becomes available for all archs. However, we lose the ability to have multiple 2.6's in a release, which sounds like a win to me; we shouldn't be doing multiple 2.6 releases anymore anyways, the security team has made it clear they don't want to support multiple kernels, and it would be extra pressure for all archs to keep up. This makes it unlikely to ever get working mips/mipsel kernels in the single source package. Perhaps you could give a reason why this is the case? Because I'm currently at 2.5 of ~8 subarchitectures working for 2.6.12, and I hear already talk about 2.6.13. I wasn't aware that you worked on mips/mipsel stuff for older kernels in the archive anyways, except for the case when we decide to stabilize on a certain version for a release. In any case, now that experimental is autobuilt, we can upload a new kernel to it and stabilize architectures, while simultaneously updating the older version in sid Does this mean to maintain two separate tracks then? Moving the experimental package to unstable could never be done when it is constantly updated. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
