All of lore.kernel.org
 help / color / mirror / Atom feed
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
Date: Wed, 12 Apr 2017 14:48:55 +0200	[thread overview]
Message-ID: <20170412124855.GA22799@kroah.com> (raw)
In-Reply-To: <CAKMK7uGwhDH9RHp9AB0Z4=-u9vpHfKmq6xQ-WHTNdmoPH6Ocnw@mail.gmail.com>

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.

So, including all of the mess where you are sending patches to Linus in
multiple branches tagged for stable, confusing the heck out of things,
combined with the extreemly low percentage of patches that actually
apply, can I just ask for you all to send me a list of commit ids, or
patches in the format that DaveM does for networking, for i915 stable
patches?  As it is, it's not working for me, nor you, so something has
to change.

And yes, I have said that I don't want to impose extra work on
maintainers for stable stuff, but right now, you are wasting stable
developers time with this low percentage rate, and ending up with a
miss-match of patches that I bet you all don't even know if it works or
not, making things even worse overall for our users.

thanks,

greg k-h

  reply	other threads:[~2017-04-12 12:49 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-12 19:44 The i915 stable patch marking is totally broken Greg KH
2017-03-12 20:11 ` Dave Airlie
2017-03-12 20:11   ` Dave Airlie
2017-03-12 21:52   ` Greg KH
2017-03-13  6:49     ` [Intel-gfx] " Daniel Vetter
2017-04-12 12:48       ` Greg KH [this message]
2017-04-12 12:57         ` Greg KH
2017-04-12 12:57           ` Greg KH
2017-03-12 20:46 ` [Intel-gfx] " Daniel Vetter
2017-03-12 20:46   ` Daniel Vetter
2017-03-12 22:01   ` [Intel-gfx] " Greg KH
2017-03-12 22:01     ` Greg KH
2017-03-13  6:40     ` [Intel-gfx] " Daniel Vetter
2017-03-13 10:41       ` Jani Nikula
2017-03-16  7:38       ` Daniel Vetter
2017-03-16  7:38         ` Daniel Vetter
2017-03-16 14:02         ` [Intel-gfx] " Greg KH
2017-03-16 14:02           ` Greg KH
2017-03-16 14:40           ` [Intel-gfx] " Jani Nikula
2017-03-16 14:40             ` Jani Nikula
2017-03-17  1:21             ` [Intel-gfx] " Greg KH
2017-03-17  1:21               ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170412124855.GA22799@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=airlied@gmail.com \
    --cc=daniel.vetter@intel.com \
    --cc=daniel@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.