On Tue, Mar 13, 2012 at 12:56:40PM +0100, Ingo Molnar wrote: > > * Russell King <rmk@xxxxxxxxxxxxxxxx> wrote: > > > On Tue, Mar 13, 2012 at 11:19:00AM +0100, Ingo Molnar wrote: > > > > > > * Russell King <rmk@xxxxxxxxxxxxxxxx> wrote: > > > > > > > On Tue, Mar 13, 2012 at 10:26:49AM +0100, Ingo Molnar wrote: > > > > > > > > > > As I said it in my first mail, doing that is unnecessary - > > > > > but if you insist on being difficult then Catalin, feel free > > > > > to pull the patch from tip:sched/arch: > > > > > > > > Nope, I'm not taking the tree anymore, [...] > > > > > > So instead of saying "sure, lets avoid conflicts next time > > > around" you are now *refusing* to take technically perfectly > > > fine patches just because another maintainer asked you to use a > > > different workflow for future patches? Wow ... > > > > No, I'm pissed off at how you're treating me over this trivial issue, > > so I'm taking the easy way out and getting out of the way. If you want > > to run your bit of the tree with idiotic rules about zero conflicts, > > and "git solutions" then that's your perogative. Just don't expect > > other people to play with you. > > > > The fact of the matter is that Peter Z. was fully aware of what was > > happening. He was aware that he'd been asked for his ack for that > > patch (because I'd explicitly asked Peter for it, but not by email) - > > and he provided his ack for that patch to Catalin: > > > > http://lists.arm.linux.org.uk/lurker/message/20120227.144813.5614e7f8.en.html > > > > Catalin sent a pull request to me, copying Peter Z on the 27th Feb: > > > > http://lists.arm.linux.org.uk/lurker/message/20120227.164502.6b58a37e.en.html > > > > I pulled it into my tree for testing, and pushed it out in the last > > couple of days. > > > > Moreover, these kinds of trivial conflicts are the type of things which > > Linus wants to see between trees. It allows him to get a feel for what's > > going on, and makes Linus feel like he's more on top of things. Linus > > said that he would like to see these trivial conflicts (he said so to me > > in an email dated 15th Jan 2011). > > > > So please, stop your insistance on this zero conflict crap. > > While I still think this is a storm in a teacup, I think you are > subtly misunderstanding Linus's position about conflicts and you > are seriously misrepresenting my request and my position as > well: > > The thing is, most conflicts are fine in general. So on one hand > you are right, we *do* allow and quite often *keep* conflicts in > place even within our own topic branches. > > Those are *real* conflicts that Linus would arguably be > interested in: two teams working on two things in parallel that > somehow conflict at the code level content-wise or concept-wise > - high level maintainers rightfully are curious about those > kinds of conflicts because while often they are just fine, it > might also be the canary of possible workflow problems or it > might also be the canary of the code being shaped in some > inefficient way. > > On the other hand, this particular conflict you pushed to > linux-next is *neither*, and this is what got my attention. This > is a plain *STUPID* conflict. > > Look into the fine conflict report Russell: it conflicts with > *Linus's* tree, because it's based off some random > barely-beyond-rc1 development window -rc3 base. Even at the > commit date of Feb 27 we had a more stable base tree available - > and especially when you pulled it, several weeks down the line, > -rc3 was not a defensible base for the integrated result. > > Having a patch applied to an old scheduler tree that is barely > out of -rc1 and then pushing it out into linux-next at -rc8, > without even checking how it integrates with upstream, barely a > few days before the merge window is just plain stupid. > > While nothing of what you talked to PeterZ is visible in the > public record, I'm quite sure had you asked him about what base > kernel to use, he'd have suggested something much more stable > ... Why am _I_ responsible for which kernel version _Catalin_ used for _his_ patches when _he_ committed them? You're insane. Totally. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
