Date: Wed, 12 Apr 2017 14:57:56 +0200
From: Greg KH <gregkh@linuxfoundation.org>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Dave Airlie <airlied@gmail.com>,
        Daniel Vetter <daniel.vetter@intel.com>,
        "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>,
        stable <stable@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [Intel-gfx] The i915 stable patch marking is totally broken
Message-ID: <20170412125756.GA2515@kroah.com>
References: <20170312194440.GA32007@kroah.com>
 <CAPM=9tycm_2dQ+3TYySEY4e4AFq9zDbsSH5donvNrFucG=vecg@mail.gmail.com>
 <20170312215215.GA30510@kroah.com>
 <CAKMK7uGwhDH9RHp9AB0Z4=-u9vpHfKmq6xQ-WHTNdmoPH6Ocnw@mail.gmail.com>
 <20170412124855.GA22799@kroah.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170412124855.GA22799@kroah.com>
User-Agent: Mutt/1.8.0 (2017-02-23)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2301
Lines: 42

On Wed, Apr 12, 2017 at 02:48:55PM +0200, Greg KH wrote:
> On Mon, Mar 13, 2017 at 07:49:59AM +0100, Daniel Vetter wrote:
> > On Sun, Mar 12, 2017 at 10:52 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > > Why don't the maintainers know which tree to put them in when they are
> > > submitted?  As an example, if I get a patch that needs to go to Linus, I
> > > put it in my usb-linus branch, and when it hits a -rc release, I then
> > > merge that -rc back into my usb-next branch.  So I end up with about 2-3
> > > merges to -rc every release, which isn't bad and doesn't cause any
> > > duplication issues.
> > >
> > > Seems that most other subsystems also do this as well.
> > 
> > We do know (mostly) where a patch should go to, and we do push a
> > backmerge every 1-2 weeks or so, too.
> > 
> > The reason why we've started to require that every bugfix for drm/i915
> > land in -next first is fairly similar to why you insist every bugfix
> > must be in Linus' tree: Without that patches get lost. Well, they
> > don't get lost intentionally (they're all still in the git log for us
> > due to backmerges), but we did lose some in the horrible resulting
> > conflicts. Insisting that we have them in our -next branch means the
> > backmerges can be resolved with git merge -x ours.
> > 
> > And in the end this is how it's done byalmost everyone: You push to
> > master and cherry-pick over to stable/release branches. Most projects
> > don't apply bugfixes to the stable branch and then backmerge to their
> > master branch, because it would result in pure chaos. You don't do
> > that either for stable kernel. It's just that for most subsystems the
> > resulting conflict gallore of using backmerges is fairly manageable
> > (it's getting into the no-fun territory with drm core too, but still
> > ok), whereas drm/i915 is just too much, moving too fast, to make that
> > a working model.
> 
> Ok, I agree that your code is moving too fast for the "normal" stable
> model here.  I just tried to apply a potential 17 patches and only 8
> applied.  That's not a good percentage.

Ok, the last remaining ones (all 6) in my queue, did apply cleanly, so
your percentage went up a bit more, but it's still the worst of any part
of the kernel and I don't think this is working as-is.

greg k-h