* Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> 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-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
