From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755346AbdEETqu (ORCPT ); Fri, 5 May 2017 15:46:50 -0400 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:43254 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752409AbdEETqt (ORCPT ); Fri, 5 May 2017 15:46:49 -0400 Message-ID: <1494013607.2399.46.camel@HansenPartnership.com> Subject: Re: [GIT PULL] Char/Misc driver patches for 4.12-rc1 From: James Bottomley To: Greg KH Cc: Linus Torvalds , Jarkko Sakkinen , Andrew Morton , Arnd Bergmann , Linux Kernel Mailing List Date: Fri, 05 May 2017 12:46:47 -0700 In-Reply-To: <20170505163846.GA31211@kroah.com> References: <20170505001808.GA16769@kroah.com> <1494000006.2399.7.camel@HansenPartnership.com> <20170505163846.GA31211@kroah.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.16.5 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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