Message-ID: <20180501205448.GE10479@thunk.org>
Date:   Tue, 1 May 2018 16:54:48 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Sasha Levin <Alexander.Levin@...rosoft.com>
Cc:     "ksummit-discuss@...ts.linuxfoundation.org" 
        <ksummit-discuss@...ts.linuxfoundation.org>,
        Greg KH <gregkh@...uxfoundation.org>, "w@....eu" <w@....eu>,
        "julia.lawall@...6.fr" <julia.lawall@...6.fr>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: bug-introducing patches

On Tue, May 01, 2018 at 08:00:21PM +0000, Sasha Levin wrote:
> 
> Yes, linux-next users want it fixed *now* and I completely agree it
> should be done that way, but the fix should not be immediately pushed to
> Linus as well.

I should have linux-head/linux-rc said testers, sorry.  The fact that
we have very few live users testing linux-next is a separate problem,
which I accidentally conflated.  But if a user who is testing -rc2
finds a problem, it is highly desirable to send a fix for -rc3,
instead of making that user wait to -rc4 or -rc5.  And *that* is more
important than AUTOSEL.

> I've just finished reading an interesting article on LWN about the
> PostgreSQL fsync issues (https://lwn.net/Articles/752952/). If you
> look at Willy's commit, he wrote the final version of it about 5 days
> ago, Jeff merged it in 3 days ago, and Linus merged it in the tree
> today. Did it spend any time getting -next testing? nope.

I agree that having the errseq patch go straight into Linus's tree is
certainly unfortunate.  The justification was this was a regression
fix, which I don't think it qualifies, since errseq_t went in some 9+
months ago.

It might be a good thing to quantify whether the patches you are
talking about are new features, bug fixes, or fixing a bug that was
introduced during the merge window or subsequently (e.g., a
regression).

> What's worse is that that commit is tagged for stable, which means
> that (given Greg's schedule) it may find it's way to -stable users
> even before some -next users/bots had a chance to test it out.

Well, it used to be that things tagged for stable most-merge window
are *supposed* to marinate for at least a week or before they would
get pulled into a stable release.  Part of the whole problem is that
people are wanting to be a lot more aggressive (both in time and
volume) in shovelling things into stable.

> This is less about AUTOSEL, and more about asking maintainers to
> improve the testing commits get before they are sent to Linus.
> Linus would rant about commits during merge window that didn't go
> through -next, but for -rc commits this rule is somehow forgiven,
> which is what I'm trying to change.

I do think it's about AUTOSEL, because when I'm dealing with a
regression, I want to get it fixed fast.  Because the alternative is
the merge-window commit getting reverted.  AUTOSEL seems wants perfect
patches that it can cherry pick once, as opposed to a case where if the
user confirms that it fixes the regression, I want to send it to Linus
quickly.  I do *not* want it to marinate in linux-next for 1-2 weeks.
I would much rather that *stable* hold off on picking up the patch for
1-2 weeks, but get it fixed in Linux HEAD sooner.  If that means that
the regression fix needs a further clean up, so be it.

Post -rc3 or -rc4, in my opinion bug fixes should wait until the next
merge window before they get merged at all.  (And certainly features
bugs should be Right Out.)  And sure, bug fixes should certainly get
more testing.  So I guess my main objection is your making a blanket
statement about all fixes, instead of breaking out regression fixes
versus bug fixes.  Since in my opinion they are very different animals...

       	   	   	       	       	    - Ted

Powered by blists - more mailing lists