On Mon 2018-04-16 16:02:03, Sasha Levin wrote: > On Mon, Apr 16, 2018 at 11:36:29AM -0400, Steven Rostedt wrote: > >On Mon, 16 Apr 2018 08:18:09 -0700 > >Linus Torvalds <torva...@linux-foundation.org> wrote: > > > >> On Mon, Apr 16, 2018 at 6:30 AM, Steven Rostedt <rost...@goodmis.org> > >> wrote: > >> > > >> > I wonder if the "AUTOSEL" patches should at least have an "ack-by" from > >> > someone before they are pulled in. Otherwise there may be some subtle > >> > issues that can find their way into stable releases. > >> > >> I don't know about anybody else, but I get so many of the patch-bot > >> patches for stable etc that I will *not* reply to normal cases. Only > >> if there's some issue with a patch will I reply. > >> > >> I probably do get more than most, but still - requiring active > >> participation for the steady flow of normal stable patches is almost > >> pointless. > >> > >> Just look at the subject line of this thread. The numbers are so big > >> that you almost need exponential notation for them. > >> > > > >I'm worried about just backporting patches that nobody actually looked > >at. Is someone going through and vetting that these should definitely > >be added to stable. I would like to have some trusted human (doesn't > >even need to be the author or maintainer of the patch) to look at all > >the patches before they are applied. > > I do go through every single commit sent this way and review it. > Sometimes things slip by, but it's not a fully automatic process. > > Let's look at this patch as a concrete example: the only reason, > according to the stable rules, that it shouldn't go in -stable is that > it's longer than 100 lines. > > Otherwise, it fixes a bug, it doesn't introduce any new features, it's > upstream, and so on. It had some fixes that went upstream as well? > Great, let's grab those as well. > > >I would say anything more than a trivial patch would require author or > >sub maintainer ack. Look at this patch, I don't think it should go to > >stable, even though it does fix issues. But the fix is for systems > >already having issues, and this keeps printk from making things worse. > >The fix has side effects that other commits have addressed, and if this > >patch gets backported, those other ones must too. > > Sure, let's get those patches in as well. > > One of the things Greg is pushing strongly for is "bug compatibility": > we want the kernel to behave the same way between mainline and stable. > If the code is broken, it should be broken in the same way.
Maybe Greg should be Cced on this conversation? Anyway, I don't think "bug compatibility" is a good goal. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Description: Digital signature