Message-ID: <20110516094056.GA25039@elte.hu>
Date:	Mon, 16 May 2011 11:40:56 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Stephen Rothwell <sfr@...b.auug.org.au>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Peter Zijlstra <peterz@...radead.org>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	John Stultz <john.stultz@...aro.org>,
	Jacob Pan <jacob.jun.pan@...el.com>,
	Glauber Costa <glommer@...hat.com>,
	Dimitri Sivanich <sivanich@....com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Jeremy Fitzhardinge <jeremy@...source.com>,
	Chris McDermott <lcm@...ibm.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Subject: Re: linux-next: manual merge of the tip tree with the arm tree


* Russell King - ARM Linux <linux@....linux.org.uk> wrote:

> On Mon, May 16, 2011 at 11:17:44AM +0200, Ingo Molnar wrote:
> > Since in the sentence you quote i only repeated what you said above (that you 
> > keep commits in Git from before when they are posted: i do that too for 
> > development) i have trouble following your line of thought of how you could 
> > possibly have concluded that i'm "not listening".
> 
> I'm saying you're not listening because I've described the workflow, [...]

And i've said that your workflow is broken for this particular case and you 
have not reacted to my various descriptions of how your workflow is broken in 
this particular case.

> [...] I've told you that what appeared in linux-next was still subject to 
> change, [...]

That's not a proper Git workflow: linux-next is *not* a playing ground to break 
arbitrarily in an *intentional* fashion like that.

linux-next has enough trouble sorting out the *unintentional* breakages and 
spurious conflicts!

Consider linux-next conflicts as a canary for workflow problems. It works very 
well in that regard.

The thing is, if sfr has trouble sorting out the conflict we caused here, while 
he does a dozen conflict resolutions a week 365 days a year, consider the 
workflow problematic by definition ...

So please get your workflow in shape as i suggested:

 - When you seriously modify or move files that other maintainers maintain in
   their trees then you first need to wait for the opinion of those 
   maintainers (and not assume lack of ack after 24 hours means acceptance), or 
   at least you need to *check* linux-next/master whether those files are truly
   quiet in this particular cycle ...

It's only common-sense and not hard to do at all!

That way you can avoid most breakages and conflicts both of technical and 
social nature *before* pushing things to linux-next. As you are doing things 
now you are driving blind in essence, that way you are *asking* for trouble and 
conflicts down the road, and that is sad and i cannot just accept it silently.

I think you are too used to being able to do anything within the ARM Git space 
and getting away with it if you mess up?

If you have a workflow that seriously modifies other trees without realizing 
that those trees have in-flight changes then you have a broken workflow, simple 
as that. And yes, i myself messed up such things in the past as well and 
modified my workflow to handle such things better.

> [...] and yet _you) persist in telling me that what I put in there was the 
> "final" commit. [...]

Yes, because you pushed it out for others to see and it showed up in 
linux-next?

Thanks,

	Ingo
--
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