Message-ID: <20170317012123.GB31078@kroah.com>
Date:   Fri, 17 Mar 2017 10:21:23 +0900
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Jani Nikula <jani.nikula@...ux.intel.com>
Cc:     Daniel Vetter <daniel.vetter@...el.com>,
        intel-gfx <intel-gfx@...ts.freedesktop.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        stable <stable@...r.kernel.org>
Subject: Re: [Intel-gfx] The i915 stable patch marking is totally broken

On Thu, Mar 16, 2017 at 04:40:01PM +0200, Jani Nikula wrote:
> On Thu, 16 Mar 2017, Greg KH <gregkh@...uxfoundation.org> wrote:
> > And again, you all are the only ones that have this issue.  You might
> > find a handfull of patches for stable that come in twice in the rest of
> > the kernel, but your "little" driver dwarfs that by an order of
> > magnitude.  I really think you are doing it wrong, no one else seems to
> > have this issue...
> 
> Just perhaps we have really active development with lots of diligence in
> tagging fixes with Fixes: and Cc: stable, and not so many others do?

While you might think so, no, lots of other subsystems have lots of
stable patches, you aren't alone there :)

> > I'll be back home next week and look into writing some scripts for this,
> > but please consider just switching your "which branch does it go into
> > first" model, which would really save me a ton of time, and remove
> > confusion from anyone who ever runs across one of these cherry-pick
> > messages.
> 
> Usually our development branches are months ahead of what's currently
> happening in Linus' master. We already have tons of stuff ready for
> v4.12, and at around v4.11-rc5 we start aiming at v4.13. This is what
> everyone wants us to do, be ready earlier and earlier for the merge
> windows.

That's fine, and again, much like everyone else.

> It is *much* easier for us to grind the fixes through our CI and QA on
> our development branches, make sure the fixes are good and compatible
> with what's coming ahead, and that the issues stay fixed. When we merge
> Linus' master and our -next, we can always trivially resolve the
> conflict to what's in our -next, and the fixes are not lost. And if we
> find issues with the commits, we can choose to not cherry-pick them
> until they're fixed.
> 
> In the past, we did have lots of trouble with people fixing issues in
> our development branches (because that's what you develop on), and the
> fixes would not apply to Linus' master. We'd redo the patch, and end up
> with nasty conflicts with what's in -next. We ended up stalling on fixes
> in *both* branches. I think we did a much worse job getting things done
> with the reverse order of applying fixes, because it was so much harder
> for us.

Huh?  You are saying that today you fix things on the development branch
(-next), and then cherry-pick to your -linus branch, right?  That's why
the git hashes are "odd".  But you said that when you did this in the
past you had problems?  I don't understand what is different now.

> In the end, the model is not unlike the stable workflow. It's just that
> stable doesn't merge back with Linus' master.

No, it's very different.  I am "cherry-picking" patches from Linus's
master into the stable branches.  The commits in the whole tree always
refer to another patch that is in the same repo.  None of this "go look
over here in linux-next for something that we hope will land in Linus's
tree in 3 months" type crap.  The sha1 references in a repo should
_always_ be resolvable in that same repo at the same point in time.
Otherwise you are playing a game where you hope things get resolved
sometime in the future.

Again, that's my biggest objection to what you all are doing, I'm amazed
that Linus hasn't complained either.

thanks,

greg k-h

Powered by blists - more mailing lists