Date:	Fri, 12 Nov 2010 09:50:04 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Chris Wilson <chris@...is-wilson.co.uk>
Cc:	Dave Airlie <airlied@...ux.ie>, linux-kernel@...r.kernel.org,
	DRI mailing list <dri-devel@...ts.freedesktop.org>
Subject: Re: [git pull] drm fixes

On Fri, Nov 12, 2010 at 9:21 AM, Chris Wilson <chris@...is-wilson.co.uk> wrote:
>
> My bad, I cherry-picked it from our public drm-intel-next tree and thought
> it wise to include the cross-reference to explain the duplication and
> merge conflicts and to provide some additional test history into the commit.
> Obviously not enough information.
>
> Is there a right approach here? I'm trying to be strict in that what is
> sent upstream in -fixes are purely known regression fixes, and to preserve
> test history on both -fixes and -next. That leads to situations like the
> above where we have a commit that does not appear to relevant to stable at
> first, but then is later shown to be required. How best to resolve the
> eventual conflict that will show up in your tree? Just cherry-pick and be
> dammed?

Generally "just cherry-pick and be damned". Duplicate patches happen
all the time, and it has nothing to do with cherry-picking: the same
patch gets done by two different people (or just forwarded to two
different maintainers). So duplication isn't problematic per se.

And if it happens so much that it then causes real problems elsewhere
(for example lots of merge conflicts due to other related changes
around it), that's indicative of something _else_ going on.

Maybe it's just a lack of good topic branches, so that you mix
everything up in one place, and get conflicts due to that. With well
chosen topic branches, you do fixes in one particular branch that can
be merged into both -next and -stable. But then you really have to do
topic branches based on _topic_, not just "this is a random collection
of -stable crap". Name the branch by the actual problem it fixes, and
do NOT merge it into either -next _nor_ -stable until that particular
problem has really been fixed and you're sure (otherwise you'll just
end up with lots of daily merges of random fixes, and that will be
_worse_. You may avoid the merge conflicts, but your history will look
like sh*t, and your topic branches will be meaningless).

Or you have two people who work in the same area, and your code is
just not modular enough, so when they work on the same file, they
invariably step on each others fingers. Functions too big, actions not
clearly enough abstracted out, people just adding things to the same
area even when they work on two different chips (the intel DRM code
tends to be _full_ of "common" functions that then test individual
chip ID's and do different things. Dammit, if they do that, they
aren't common functions, and you write them the wrong way around:
instead of having "common function testing if ID==sandybridge", you
should have "sandybridge function doing its thing and calling _truly_
common helper functions that do things that other chip functions will
need too")

Merge conflicts (of anything but the totally trivial kind) are almost
always a sign of something being wrong in the development.  Trivial
merge conflicts (and merges that had the same patch and got resolved
totally automatically - they were so trivial that a human never even
saw it) are normal. But if it's at the point that it causes pain,
there is some more fundamental problem, and marking commits as "this
is the same as in that other branch" is not the solution.

                           Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists