On Sun, 20 Feb 2011 08:24:32 +0100 Lucas Nussbaum wrote:
> On 19/02/11 at 17:40 -0500, Michael Gilbert wrote:
> > On Sat, 19 Feb 2011 21:39:03 + Ben Hutchings wrote:
> > > > Hypothesis 1: using an older kernel in testing results in fewer
> > > > vulnerabilities
> > > >
> > > > Criteria: fe
On 19/02/11 at 17:40 -0500, Michael Gilbert wrote:
> On Sat, 19 Feb 2011 21:39:03 + Ben Hutchings wrote:
> > > Hypothesis 1: using an older kernel in testing results in fewer
> > > vulnerabilities
> > >
> > > Criteria: fewer vulnerabilities in lenny than squeeze during squeeze
> > > testin
On Sat, Feb 19, 2011 at 04:58:50PM -0500, Michael Gilbert wrote:
> On Sat, 19 Feb 2011 22:28:17 +0100 Bastian Blank wrote:
> > On Sat, Feb 19, 2011 at 03:55:03PM -0500, Michael Gilbert wrote:
> > > Hypothesis 1: using an older kernel in testing results in fewer
> > > vulnerabilities
> > > Eviden
On Sat, 19 Feb 2011 21:39:03 + Ben Hutchings wrote:
> > Hypothesis 1: using an older kernel in testing results in fewer
> > vulnerabilities
> >
> > Criteria: fewer vulnerabilities in lenny than squeeze during squeeze
> > testing cycle
> > Evidence: lenny's kernel was vulnerable to 67% of
On Sat, 19 Feb 2011 22:28:17 +0100 Bastian Blank wrote:
> On Sat, Feb 19, 2011 at 03:55:03PM -0500, Michael Gilbert wrote:
> > Hypothesis 1: using an older kernel in testing results in fewer
> > vulnerabilities
> >
> > Criteria: fewer vulnerabilities in lenny than squeeze during squeeze
> > t
On Sat, 2011-02-19 at 15:55 -0500, Michael Gilbert wrote:
> On Sat, 19 Feb 2011 20:30:47 + Ben Hutchings wrote:
>
> > On Sat, 2011-02-19 at 14:59 -0500, Michael Gilbert wrote:
> > > On Sat, 19 Feb 2011 19:32:08 + Ben Hutchings wrote:
> > [...]
> > > > > Again, if the user is interested in
On Sat, Feb 19, 2011 at 03:55:03PM -0500, Michael Gilbert wrote:
> Hypothesis 1: using an older kernel in testing results in fewer
> vulnerabilities
>
> Criteria: fewer vulnerabilities in lenny than squeeze during squeeze
> testing cycle
> Evidence: lenny's kernel was vulnerable to 67% of th
On sam., 2011-02-19 at 15:55 -0500, Michael Gilbert wrote:
> I can't imagine anyone else being put through such a arduous process
> to try an experiment for a couple months. Why does it have to be so
> difficult?
Because noone else wants Wheezy to be stuck at 2.6.32 when 2.6.37/38 are
available.
On Sat, 19 Feb 2011 20:30:47 + Ben Hutchings wrote:
> On Sat, 2011-02-19 at 14:59 -0500, Michael Gilbert wrote:
> > On Sat, 19 Feb 2011 19:32:08 + Ben Hutchings wrote:
> [...]
> > > > Again, if the user is interested in such new developments, they will
> > > > need to be willing to learn h
On Sat, 19 Feb 2011 14:59:27 -0500 Michael Gilbert wrote:
> On Sat, 19 Feb 2011 19:32:08 + Ben Hutchings wrote:
>
> > On Sat, 2011-02-19 at 14:04 -0500, Michael Gilbert wrote:
> > > On Sat, 19 Feb 2011 18:48:40 + Ben Hutchings wrote:
> > >
> > > > On Sat, 2011-02-19 at 13:12 -0500, Micha
On Sat, 2011-02-19 at 14:59 -0500, Michael Gilbert wrote:
> On Sat, 19 Feb 2011 19:32:08 + Ben Hutchings wrote:
[...]
> > > Again, if the user is interested in such new developments, they will
> > > need to be willing to learn how to run an unstable system.
> >
> > I thought that users interes
On Sat, 19 Feb 2011 19:32:08 + Ben Hutchings wrote:
> On Sat, 2011-02-19 at 14:04 -0500, Michael Gilbert wrote:
> > On Sat, 19 Feb 2011 18:48:40 + Ben Hutchings wrote:
> >
> > > On Sat, 2011-02-19 at 13:12 -0500, Michael Gilbert wrote:
> [...]
> > > > 2. Improve testing security by reduci
On Sat, 2011-02-19 at 14:04 -0500, Michael Gilbert wrote:
> On Sat, 19 Feb 2011 18:48:40 + Ben Hutchings wrote:
>
> > On Sat, 2011-02-19 at 13:12 -0500, Michael Gilbert wrote:
[...]
> > > 2. Improve testing security by reducing the amount of vulnerabilities
> > > existent in older kernels (rou
On Sat, 19 Feb 2011 18:48:40 + Ben Hutchings wrote:
> On Sat, 2011-02-19 at 13:12 -0500, Michael Gilbert wrote:
> [...]
> > Also, this solution isn't just about CUT stability. As I've been
> > describing, it is about killing about 2 birds with one stone:
> >
> > 1. Make testing always instal
On Sat, 2011-02-19 at 13:12 -0500, Michael Gilbert wrote:
[...]
> Also, this solution isn't just about CUT stability. As I've been
> describing, it is about killing about 2 birds with one stone:
>
> 1. Make testing always installable by retaining a stable/well-tested
> kernel and associated d-i i
On Sat, 19 Feb 2011 14:09:50 +0100 Raphael Hertzog wrote:
> On Fri, 18 Feb 2011, Michael Gilbert wrote:
> > This will also help to provide a bit more stability for CUT [0]. Over
> > a 1.5-year period (the non-freeze timeframe) roughly 6 new upstream
> > kernels will be released, and each new kern
On Fri, 18 Feb 2011, Michael Gilbert wrote:
> This will also help to provide a bit more stability for CUT [0]. Over
> a 1.5-year period (the non-freeze timeframe) roughly 6 new upstream
> kernels will be released, and each new kernel comes along with a high
> probability of introducing breakage.
On 18/02/11 at 17:24 -0500, Michael Gilbert wrote:
> On Mon, 7 Feb 2011 22:54:53 -0500 Michael Gilbert wrote:
> > On Sun, 6 Feb 2011 21:58:08 -0400, Joey Hess wrote:
> > > Michael Gilbert wrote:
> > > > Another issue was that a lot of vulnerabilities that were found in that
> > > > time frame were
On Fri, 2011-02-18 at 17:24 -0500, Michael Gilbert wrote:
[...]
> If there is some concurrence on this, I'll submit an RC blocker bug on
> the kernel. Note there are only 8 days to discuss before the
> transition is automatic (I think the current RC blocker [1] may
> disappear by then).
I don't r
On Mon, 7 Feb 2011 22:54:53 -0500 Michael Gilbert wrote:
> On Sun, 6 Feb 2011 21:58:08 -0400, Joey Hess wrote:
> > Michael Gilbert wrote:
> > > Another issue was that a lot of vulnerabilities that were found in that
> > > time frame were actually flaws in new kernel code, so testing/unstable
> > >
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
On Mon, 7 Feb 2011 22:54:53 -0500 Michael Gilbert wrote:
> Even playing the numbers game with a bit more thoughtful analysis with
> the LWN data, lenny looks a lot better. It can be seen that lenny
> (2.6.26) was vulnerable to 69% (36 out of 52) of the vulnerabilities
> listed there, and squeeze (
Hi Joey,
Thank you so much for your very thoughtful reply.
On Sun, 6 Feb 2011 21:58:08 -0400, Joey Hess wrote:
> Michael Gilbert wrote:
> > Another issue was that a lot of vulnerabilities that were found in that
> > time frame were actually flaws in new kernel code, so testing/unstable
> > were v
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 fix
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,
2011/2/7 Ben Hutchings wrote:
> On Mon, Feb 07, 2011 at 07:12:48PM +0100, Moritz Mühlenhoff wrote:
>> Michael Gilbert 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,
>> > reevaluat
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 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 mont
On Mon, 7 Feb 2011 19:12:48 +0100, Moritz Mühlenhoff wrote:
> Michael Gilbert 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 caden
On Mon, Feb 07, 2011 at 07:12:48PM +0100, Moritz Mühlenhoff wrote:
> Michael Gilbert 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 longter
Michael Gilbert 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 expe
Well, I have a few horses in this race in between testing-security,
d-i, and CUT, as well as having been a Release Assistant in the past,
and I think this proposal stinks from every perspective.
Michael Gilbert wrote:
> The biggest problem I saw during the squeeze development cycle was that
> kern
Hi,
Now that squeeze is released, I've started thinking about how to
improve the quality of security support for testing.
The biggest problem I saw during the squeeze development cycle was that
kernel security update transitions were extremely slow due to unrelated
RC bugs. This was bad since
32 matches
Mail list logo
