lkml.org 
[lkml]   [2013]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [ 00/19] 3.10.1-stable review
On Fri, Jul 12, 2013 at 03:49:11PM -0400, Steven Rostedt wrote:
> On Fri, 2013-07-12 at 15:35 -0400, Theodore Ts'o wrote:
>
> > So the problem is that maintainers are lazy. They don't want to go
> > back for bug fixes that have "proven" themselves, and even if they
> > aren't critical bug fixes, they are things which a distro maintainer
> > or a stable kernel user might want (and sometimes stable uers are
> > uppity enough to expect subsystem maintainers to do this back
> > porting). So subsystem maintainers then react by marking submits for
> > stable even though they really should soak for a release or two before
> > submitting them, since by marking them as submit, the commit gets
> > pushed to stable automatically --- albeit early.
>
> Actually, this is a very good point. There were one or two stable
> patches I had pushed to linux-next that I wasn't too comfortable about.
> If the fix goes back to older trees, I rather have them stirring in
> linux-next and push it in the next merge window instead of pushing it to
> Linus and have it go to stable immediately.
>
> Unless its a obvious fix, I tend to take about a month from the time I
> get a stable fix to the time I push it out. Making sure the stable fix
> doesn't introduce new bugs.

Like most of the other examples in this thread, one size doesn't fit all though.

Your example above: If that fix was for "tracing reports wrong results", no big deal,
everyone can live with it for a month. If it was fixing "a bug in tracing can allow
an unprivileged user to crash the kernel", a month is unacceptable, and at
the least we should be getting an interim fix to mitigate the problem.

Dave



\
 
 \ /
  Last update: 2013-07-12 22:41    [W:0.207 / U:0.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site