Re: [GIT PULL] late arch/metag fixes for v3.9-rc1

[James Hogan]

On 02/03/13 16:28, Linus Torvalds wrote:
> You are the
> architecture maintainer, and your job is not integration, it's to make
> sure that *your* work is as stable and unsurprising as possible.

Right, make sense. This is what it comes down to.

> See why I hate rebasing and back-merges so much?

Yes. To be clear I wasn't keen on the idea of rebasing the tree (which
is why I had fixes applied on top of it instead of keeping rebasing it),
but I was missing your point about not being my job to do integration so
I wasn't sure what other alternative to back-merges there was.

> Right now, I think your best option is to rebase just your own commits
> on top of v3.8, and then ask me to pull the result, with explanations
> of what the conflicts will be. And while I much prefer explanations
> (and also a general over-view, just so that I can put it in the commit
> message), I actually even prefer unexplained merge conflicts that I
> have to resolve over the "I did a back-merge at some random point
> because I was trying to be helpful, or because I wanted to use a new
> and untested feature that isn't even in a release kernel yet".

Okay,

> But I do *not* take new trees that do bad things. If I take a new
> architecture, I want to feel like I'm not just getting the
> architecture, but I'm also getting a maintainer that knows about
> keeping his history clean and not mixing with the independent work
> other people did, or messing up other people by rebasing public
> commits etc.

I actually take slightly obsessive pride in trying to have a clean
history where every commit works so that bisection doesn't break, which
is probably the problem here. I was trying too hard to make it just work
when everything is integrated (e.g. trying to make linux-next just work,
which now seems like a conflicting goal) instead of helping you do that.
Obviously I'll have to do better.

Thanks
James

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