All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
	John Stultz <john.stultz@linaro.org>,
	Jacob Pan <jacob.jun.pan@intel.com>,
	Glauber Costa <glommer@redhat.com>,
	Dimitri Sivanich <sivanich@sgi.com>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Jeremy Fitzhardinge <jeremy@xensource.com>,
	Chris McDermott <lcm@us.ibm.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: linux-next: manual merge of the tip tree with the arm tree
Date: Mon, 16 May 2011 09:31:44 +0200	[thread overview]
Message-ID: <20110516073144.GF24836@elte.hu> (raw)
In-Reply-To: <20110513213640.GB30539@n2100.arm.linux.org.uk>


* Russell King - ARM Linux <linux@arm.linux.org.uk> 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.

The commit date i pointed out was of the *final* commit, which got into 
linux-next. That showed a timestamp of just a day after the patch was sent
out: presumably you rebased it to add John's Acked-by.

The step where your workflow failed was to take upon yourself to maintain a 
file you do not normally maintain *and* messing up doing that:

 - you did not ask the maintainers who maintain it (which is fine as long as 
   you do not mess up)

 - you did not realize that the file you modified is already modified in that
   tree, almost two months ago (it's not that hard to fetch linux-next once 
   every week or so)

 - you did not even notify them that you committed something so when the bug
   happened in linux-next they had no idea what was going on

Had you done any of those steps differently we'd have a better outcome.

It's not a big problem all and we can resolve it, but you need to stop 
pretending that your workflow was just fine - it sucked here.

Thanks,

	Ingo

  reply	other threads:[~2011-05-16  7:32 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-13  3:14 linux-next: manual merge of the tip tree with the arm tree Stephen Rothwell
2011-05-13  8:06 ` Ingo Molnar
2011-05-13  8:37   ` Russell King - ARM Linux
2011-05-13  8:47     ` Thomas Gleixner
2011-05-13  9:26     ` Ingo Molnar
2011-05-13 10:04       ` Thomas Gleixner
2011-05-13 17:25       ` Russell King - ARM Linux
2011-05-16  7:21         ` Ingo Molnar
2011-05-13 21:36       ` Russell King - ARM Linux
2011-05-16  7:31         ` Ingo Molnar [this message]
2011-05-16  7:42           ` Russell King - ARM Linux
2011-05-16  9:17             ` Ingo Molnar
2011-05-16  9:19               ` Russell King - ARM Linux
2011-05-16  9:40                 ` Ingo Molnar
2011-05-16 10:07                   ` Russell King - ARM Linux
2011-05-16 11:06                     ` Ingo Molnar
2011-05-16 11:37                       ` Russell King - ARM Linux
2011-05-16 18:47                         ` John Stultz
2011-05-17 11:56                         ` Ingo Molnar
2011-05-17 18:28                           ` Russell King - ARM Linux
  -- strict thread matches above, loose matches on Subject: below --
2013-06-20  5:05 Stephen Rothwell
2020-05-29  5:29 Stephen Rothwell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110516073144.GF24836@elte.hu \
    --to=mingo@elte.hu \
    --cc=glommer@redhat.com \
    --cc=hpa@zytor.com \
    --cc=jacob.jun.pan@intel.com \
    --cc=jeremy@xensource.com \
    --cc=john.stultz@linaro.org \
    --cc=konrad.wilk@oracle.com \
    --cc=lcm@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=peterz@infradead.org \
    --cc=rusty@rustcorp.com.au \
    --cc=sfr@canb.auug.org.au \
    --cc=sivanich@sgi.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.