* 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 ... Thanks, Ingo -- 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
