lkml.org 
[lkml]   [2017]   [Apr]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Intel-gfx] The i915 stable patch marking is totally broken
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

\
 
 \ /
  Last update: 2017-04-12 14:58    [W:0.038 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site