Re: [GIT PULL] Char/Misc driver patches for 4.12-rc1

From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] Char/Misc driver patches for 4.12-rc1
Date: Fri, 05 May 2017 12:46:47 -0700	[thread overview]
Message-ID: <1494013607.2399.46.camel@HansenPartnership.com> (raw)
In-Reply-To: <20170505163846.GA31211@kroah.com>

On Fri, 2017-05-05 at 09:38 -0700, Greg KH wrote:
> On Fri, May 05, 2017 at 09:00:06AM -0700, James Bottomley wrote:
> > On Thu, 2017-05-04 at 19:28 -0700, Linus Torvalds wrote:
> > > On Thu, May 4, 2017 at 5:18 PM, Greg KH <
> > > gregkh@linuxfoundation.org>
> > > wrote:
> > > > 
> > > > Here is the big set of new char/misc driver drivers and
> > > > features 
> > > > for 4.12-rc1.
> > > 
> > > Ugh. I'm not particularly happy with the conflicts I got and my
> > > resolutions there-of.
> > 
> > Yes, we really should have done this via a postmerge tree.  We've 
> > had so little cause to use them recently, I suspect everyone's
> > forgotten how.
> 
> Huh?  You could have pulled in my tree into this one, or I could have
> done that for you, my trees are not rebased at all, and they get used
> this way every other release or so for this very reason.

Well, I think this is the process issue, isn't it?  You're telling me I
could have run the tree or you could (actually, you don't mean me: this
is a security subsystem where Jarkko sends a pull to James Morris who
sends it on to Linus so it would be JamesM running it).  I'm asking the
question why we didn't.  I think we didn't because once Stephen worked
out the merge commit everyone forgot about the problem.

So the first process question is: "is what we did what should happen". 
 We can say yes and stop here: linux-next did the merges with conflict
resolution.  The osd initial merge was wrong, so we went back on linux
-scsi and had it corrected and I remembered to send in the resolution
from linux-next with the SCSI pull request so as not to have the
obvious but wrong resolution problem happen again.  The same thing
could be done with the security tree.  I think it's easy to conclude
that this is probably good enough.

If we have more of a desire to avoid tree conflicts, then postmerge
trees could be the answer, but in in this case, since changing the
existing API users to the new API (which is where all the nasty
conflicts were) weren't really time critical, the code could have been
staged as a new API plus patches that use it in one cycle and
conversions of existing users in a second.  The later could have gone
through the proper Maintainer trees and we'd never have seen a conflict
in any of the subsystems.

James