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. Indeed, which goes down to my comment somewhere else in this thread about "Cc:stable" being used as a convenient marker for a bug fix. Let's simply have a real marker and this should flow much smoother because end users will ask "Dear stable maintainers, could we please merge this patch, I need it". Regards, Willy -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html