[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