public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: Fwd: [GIT PULL] [3.2] Please pull tegra boards for 3.2
Date: Tue, 16 Aug 2011 23:12:33 +0200	[thread overview]
Message-ID: <2300535.b0zjAbUTLi@wuerfel> (raw)
In-Reply-To: <CAOesGMgZCFF=dWhAm_+Ux-c-aORqo4sJ1DOGirCu3QT-iMcQRQ@mail.gmail.com>

On Tuesday 16 August 2011 12:30:50 Olof Johansson wrote:
> On Tue, Aug 16, 2011 at 7:48 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > The contents all look good, but I'm undecided whether we should have
> > branches that are not based on a -rc release. In your case, it's
> > halfway between -rc1 and -rc2.
> >
> > Do others have an opinion? If we decide to take development branches
> > only when they are based on a proper -rc, I'll do the simple rebase
> > of the patches and push them out, otherwise I'll push them as they are.
> 
> I guess it depends on what you and others prefer -- if you want to
> aggregate the branches in arm-soc.git through the development weeks,
> or if you prefer to get most of the merge requests when platform
> maintainers are getting ready for the merge window and feeding things
> up?

I definitely want to have the patches as early as possible, but not
more than one pull request per branch per week or -rc ideally.

> Either is fine with me -- if it's easier for me to hold off the merge
> requests a while, then I'll start a for-next branch and ask Stephen to
> add it, and rebase it a few times up until when the merge request to
> arm-soc is sent. Maybe it's just easier for everyone to do it that way
> -- the drawback is that there's less visibility about what's about to
> go in until the merge requests start to drop in late in the cycle. The
> git history won't be quite as wide then either.

I would prefer to have all branches that I send to Linus go into the
-next through the arm-soc tree as well, not get sent there individually.

Basically, when you consider patches stable and ready for upstream
and expect no further changes, I'll pull the patches into arm-soc.git
and you can add further patches on top of the branch that I have already
pulled (not on an aggregated branch) and I can pull that again. If you
have unrelated changes, then I'd prefer them to be on top of an -rc
release for the next pull request.

	Arnd

  reply	other threads:[~2011-08-16 21:12 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-14  7:35 [GIT PULL] [3.2] Please pull tegra boards for 3.2 Olof Johansson
     [not found] ` <CAOesGMhFi0fsVdTe0ThhF636tqUhiWk7oZ41QKmL4dd3TcQ4_g@mail.gmail.com>
2011-08-16 14:48   ` Fwd: " Arnd Bergmann
2011-08-16 15:03     ` Nicolas Pitre
2011-08-16 15:27       ` Thomas Gleixner
2011-08-16 19:30     ` Olof Johansson
2011-08-16 21:12       ` Arnd Bergmann [this message]
2011-08-26  5:23         ` Olof Johansson
2011-08-26  8:32           ` Russell King - ARM Linux
2011-08-26  9:15             ` Sascha Hauer
2011-08-26  5:40 ` Olof Johansson
2011-08-26 15:53   ` Arnd Bergmann

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=2300535.b0zjAbUTLi@wuerfel \
    --to=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox