Re: [Secure-testing-team] For discussion: security support strategy for the wheezy kernel
On Mon, Feb 07, 2011 at 05:15:07PM -0500, Michael Gilbert wrote: On Mon, Feb 7, 2011 at 5:09 PM, Julien Cristau wrote: What does that buy us? ??It means instead of dealing with bugs on an ongoing basis, you get them all at the same time and get to bisect along many kernel versions at once instead of just one. ??It means problems don't get reported (and fixed) upstream until it's too late. ??It means any package that could use a newer kernel interface doesn't get any testing. ??I'm sure there's plenty of others. Bugs can be submitted and dealt with in experimental just as well as in unstable. Realistically people don't generally go randomly installing things from experimental so the testing coverage we get from having unstable and testing is substantially reduced - we get to deal with everything in the freeze instead, plus all the effects of running an old kernel which isn't being actively developed. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110208130359.gc29...@sirena.org.uk
Re: [Secure-testing-team] For discussion: security support strategy for the wheezy kernel
On Mon, 7 Feb 2011 19:12:48 +0100, Moritz Mühlenhoff wrote: Michael Gilbert michael.s.gilb...@gmail.com schrieb: Hi, So, my proposal in a nutshell is to only upload upstream 2.6.32 point releases to wheezy/sid for the next 12-18 months. At that time, reevaluate and determine what the next longterm cadence kernel will be, and then once that is reasonable stabilized in experimental, finally upload it to unstable for the final stages of wheezy development (perhaps a few months before the freeze). No way. The idea of unstable is to get the current upstream code in shape and that won't be achieved with staying with an old kernel. I'm not sure if there's a precise definition of unstable other than the statement at [0], but it seems to be whatever teams make of it. It's perfectly ok to upload only stable versions (if that's what the team wants to do), and its perfectly ok to upload the most unstable thing ever, but then the consequences of that have to be dealt with. I guess what I'm saying is that each team can decide specifically how they want to use unstable, so the kernel team can deviate from the status quo if they decide to; that is if I can make a sufficiently convincing argument. Also, my suggestion does involve eventually moving to a newer kernel in the wheezy development cycle; just a while from now, rather than rushing in to things. Whatever the technical solution to testing-security kernel might be, it needs to be based on following the upstream kernel development. 2.6.32.x is in fact an upstream kernel currently being developed ;) Best wishes, Mike [0] http://www.debian.org/releases/unstable/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110207162831.fbd75367.michael.s.gilb...@gmail.com
Re: [Secure-testing-team] For discussion: security support strategy for the wheezy kernel
On Mon, Feb 7, 2011 at 16:28:31 -0500, Michael Gilbert wrote: On Mon, 7 Feb 2011 19:12:48 +0100, Moritz Mühlenhoff wrote: Michael Gilbert michael.s.gilb...@gmail.com schrieb: Hi, So, my proposal in a nutshell is to only upload upstream 2.6.32 point releases to wheezy/sid for the next 12-18 months. At that time, reevaluate and determine what the next longterm cadence kernel will be, and then once that is reasonable stabilized in experimental, finally upload it to unstable for the final stages of wheezy development (perhaps a few months before the freeze). No way. The idea of unstable is to get the current upstream code in shape and that won't be achieved with staying with an old kernel. I'm not sure if there's a precise definition of unstable other than the statement at [0], but it seems to be whatever teams make of it. unstable is where debian development work happens. It's perfectly ok to upload only stable versions (if that's what the team wants to do), and its perfectly ok to upload the most unstable thing ever, but then the consequences of that have to be dealt with. I guess what I'm saying is that each team can decide specifically how they want to use unstable, so the kernel team can deviate from the status quo if they decide to; that is if I can make a sufficiently convincing argument. Also, my suggestion does involve eventually moving to a newer kernel in the wheezy development cycle; just a while from now, rather than rushing in to things. What does that buy us? It means instead of dealing with bugs on an ongoing basis, you get them all at the same time and get to bisect along many kernel versions at once instead of just one. It means problems don't get reported (and fixed) upstream until it's too late. It means any package that could use a newer kernel interface doesn't get any testing. I'm sure there's plenty of others. Whatever the technical solution to testing-security kernel might be, it needs to be based on following the upstream kernel development. 2.6.32.x is in fact an upstream kernel currently being developed ;) No it's not. Go read the definition of development. I'm sorry, but your proposal is insane. Cheers, Julien signature.asc Description: Digital signature
Re: [Secure-testing-team] For discussion: security support strategy for the wheezy kernel
2011/2/7 Ben Hutchings wrote: On Mon, Feb 07, 2011 at 07:12:48PM +0100, Moritz Mühlenhoff wrote: Michael Gilbert michael.s.gilb...@gmail.com schrieb: Hi, So, my proposal in a nutshell is to only upload upstream 2.6.32 point releases to wheezy/sid for the next 12-18 months. At that time, reevaluate and determine what the next longterm cadence kernel will be, and then once that is reasonable stabilized in experimental, finally upload it to unstable for the final stages of wheezy development (perhaps a few months before the freeze). No way. The idea of unstable is to get the current upstream code in shape and that won't be achieved with staying with an old kernel. Whatever the technical solution to testing-security kernel might be, it needs to be based on following the upstream kernel development. Totally agreed. We should be tracking current upstream releases, and not just in experimental (which can now be used for upstream release candidates). What about introducing a new linux-2.6-stable kernel package as a compromise? That way users that want stability and security support in testing continue to have that as an option. Also, I will assume responsibility as the maintainer, so there will be hopefully very little impact to any other part of Debian. Also, I can look at generating d-i media for this kernel. Any thoughts on that? The only downside I can think of right away is introducing a huge code copy into the archive. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTin7H+4DNM90YK-6hwLaaT+m=gcpukz6xs2gr...@mail.gmail.com
Re: [Secure-testing-team] For discussion: security support strategy for the wheezy kernel
On Mon, Feb 7, 2011 at 5:08 PM, Michael Gilbert wrote: What about introducing a new linux-2.6-stable kernel package as a compromise? That way users that want stability and security support in testing continue to have that as an option. Also, I will assume responsibility as the maintainer, so there will be hopefully very little impact to any other part of Debian. Also, I can look at generating d-i media for this kernel. Any thoughts on that? The only downside I can think of right away is introducing a huge code copy into the archive. Also the same effect can be achieved by apt-pinning the squeeze kernel. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTinNLPeSzJn+VhYMFn6om0duiYrX6=m6zjn2x...@mail.gmail.com
Re: [Secure-testing-team] For discussion: security support strategy for the wheezy kernel
On Mon, Feb 7, 2011 at 5:09 PM, Julien Cristau wrote: What does that buy us? It means instead of dealing with bugs on an ongoing basis, you get them all at the same time and get to bisect along many kernel versions at once instead of just one. It means problems don't get reported (and fixed) upstream until it's too late. It means any package that could use a newer kernel interface doesn't get any testing. I'm sure there's plenty of others. Bugs can be submitted and dealt with in experimental just as well as in unstable. Whatever the technical solution to testing-security kernel might be, it needs to be based on following the upstream kernel development. 2.6.32.x is in fact an upstream kernel currently being developed ;) No it's not. Go read the definition of development. I'm sorry, but your proposal is insane. Is this kind of negativity really necessary? I'm trying to guide a discussion on a real problem, and I'm an engineer, so I never present problems without at least an idea about a solution. It may not be the best, but you start at something and work toward bettering it until you have something good. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTimiCaXv+Yhgg=UW7=1miK-Y5=aLwp9=psvh1...@mail.gmail.com
