[Ksummit-discuss] [MAINTAINER SUMMIT] Stable trees and release time

Steven Rostedt rostedt at goodmis.org
Wed Sep 5 14:44:11 UTC 2018


On Wed, 5 Sep 2018 11:11:59 +0100
Mark Brown <broonie at kernel.org> wrote:

> On Wed, Sep 05, 2018 at 10:56:42AM +0200, Greg KH wrote:
> 
> > 	- We have finally woken some subsystem maintainers up into
> > 	  actually properly tagging patches for stable.  We used to have
> > 	  a horrid rate of this happening, and it is getting better.
> > 	  However, we still have whole major subsystems that _never_ tag
> > 	  anything, which is a problem, so things will get larger.  
> 
> Some of us have been doing this for 5+ years :/

Yep.

> 
> > 	- Sasha's work in finding the patches that maintainers/developer
> > 	  fail to tag is paying off really well, which also increases
> > 	  the size.  
> 
> These and the few other patches that I didn't tag for stable myself are
> the only ones I try to review reliably, the others I already looked at
> for stable at least once and especially where things are automated it's
> better to have some manual checking.  It's good that Sasha's stuff is
> flagged now, and most other submissions are obvious as well, so that's
> fairly easy to do and means that the review burden is relatively light.

I tend to too. As there's some fixes I don't tag for stable because it
doesn't "break" things too bad (things that were always broken for
years, but nobody noticed.. like a bad format of the trace output), or
I have another fix for the problem. For instance, I just replied to an
AUTOSEL patch that fixed a symptom of a bug, but the bug fix itself was
tagged for stable. The symptom fix was just to make the code more
"robust" and shouldn't hurt anything, but it really wasn't a bug fix.
I don't think it was necessary to backport that, but if someone else
thinks it is, I'll just let it be.

-- Steve


More information about the Ksummit-discuss mailing list