Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1598902

Re: [Intel-gfx] The i915 stable patch marking is totally broken

From Daniel Vetter <daniel@ffwll.ch>
Newsgroups linux.kernel
Subject Re: [Intel-gfx] The i915 stable patch marking is totally broken
Date 2017-03-13 08:00 +0100
Message-ID <tks7v-53e-1@gated-at.bofh.it> (permalink)
References <tkhOO-65d-7@gated-at.bofh.it> <tki89-6tx-11@gated-at.bofh.it> <tkjGV-7nz-3@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

The i915 stable patch marking is totally broken Greg KH <gregkh@linuxfoundation.org> - 2017-03-12 21:00 +0100
  Re: The i915 stable patch marking is totally broken Dave Airlie <airlied@gmail.com> - 2017-03-12 21:20 +0100
    Re: The i915 stable patch marking is totally broken Greg KH <gregkh@linuxfoundation.org> - 2017-03-12 23:00 +0100
      Re: [Intel-gfx] The i915 stable patch marking is totally broken Daniel Vetter <daniel@ffwll.ch> - 2017-03-13 08:00 +0100
  Re: [Intel-gfx] The i915 stable patch marking is totally broken Daniel Vetter <daniel@ffwll.ch> - 2017-03-12 21:50 +0100
    Re: [Intel-gfx] The i915 stable patch marking is totally broken Greg KH <gregkh@linuxfoundation.org> - 2017-03-12 23:10 +0100
      Re: [Intel-gfx] The i915 stable patch marking is totally broken Daniel Vetter <daniel@ffwll.ch> - 2017-03-13 07:50 +0100
        Re: [Intel-gfx] The i915 stable patch marking is totally broken Jani Nikula <jani.nikula@linux.intel.com> - 2017-03-13 11:50 +0100

csiph-web