lkml.org 
[lkml]   [2018]   [Apr]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH AUTOSEL for 4.14 015/161] printk: Add console owner and waiter logic to load balance console writes
    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 <torvalds@linux-foundation.org> wrote:
    > >
    > >> On Mon, Apr 16, 2018 at 6:30 AM, Steven Rostedt <rostedt@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
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2018-04-16 18:11    [W:4.696 / U:0.088 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site