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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <51324D92.5090100@imgtec.com>
Date:	Sat, 2 Mar 2013 19:05:54 +0000
From:	James Hogan <james.hogan@...tec.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Arnd <arnd@...db.de>, linux-kernel <linux-kernel@...r.kernel.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>
Subject: Re: [GIT PULL] late arch/metag fixes for v3.9-rc1

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/