[lkml]   [2011]   [May]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: linux-next: manual merge of the tip tree with the arm tree

* Russell King - ARM Linux <> wrote:

> On Mon, May 16, 2011 at 09:31:44AM +0200, Ingo Molnar wrote:
> >
> > * Russell King - ARM Linux <> wrote:
> >
> > > On Fri, May 13, 2011 at 11:26:46AM +0200, Ingo Molnar wrote:
> > > >
> > > > Had you asked us before committing it one day after it was posted, or
> > > > had you *noticed* that those files are not in your tree and are already
> > > > modified in linux-next, you'd have gotten a response like:
> > >
> > > Please also don't read anything into the commit date - it merely shows
> > > when the last update happened.
> > >
> > > My workflow for patch series involves keeping them in git right from the
> > > start. So actually they've been in git since _before_ they were posted.
> > > In fact, the emails which I send out for any patch series are always
> > > generated from the git commits.
> > >
> > > So, all my patches live in git _first_ before being mailed out.
> >
> > It is not a problem at all if you commit it to some non-permanent
> > development branch of your own - we all do it.
> Clearly you're not listening, so no point discussing this further.

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 am very much listening, i just do not agree with what you are saying: i think
it's pretty clear that details of your Git workflow are broken and need to be
improved - as demonstrated by the conflict, build breakage and discussion in
this thread.

Anyway, since you unilaterally stopped discussing this topic and since there's
no acknowledgement from you that you'll fix your workflow it appears i have no
choice but to ask you to refrain from modifying any arch/x86/ code in the
future, without an explicit *prior* ack from one of the x86 maintainers.

When you do that they will be able to guide you through when various files are
proper to modify in a separate branch and what to do if there are already
changes in flight.



 \ /
  Last update: 2011-05-16 11:21    [W:0.049 / U:112.920 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site