All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ted Ts'o" <tytso@mit.edu>
To: Eric Van Hensbergen <ericvh@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	V9FS Developers <v9fs-developer@lists.sourceforge.net>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] 9p changes fro merge window
Date: Wed, 26 Oct 2011 09:22:53 -0400	[thread overview]
Message-ID: <20111026132253.GW31921@thunk.org> (raw)
In-Reply-To: <FC179A32-61E1-4B40-AE58-724D255586F8@gmail.com>

On Wed, Oct 26, 2011 at 07:48:59AM -0500, Eric Van Hensbergen wrote:
> 
> What's the preferred maintainer workflow?  I had been fetching and
> then rebasing, which seemed to keep my shortlog clean of merge
> commits and the outstanding patches towards the top.  Should I just
> be pulling from upstream and not caring about the merge commits?

Don't fetch or merge from upstream at all.  For this merge window I've
done all of my development based on v3.1-rc3.  Periodically I'll fetch
from upstream, and I'll do trail merges with upstream on a throwaway
patch just to make things will work or to be alerted of any merge
conflicts.  (Actually, linux-next is really good for that as well.)

> Also, as a point of clarification, if I do get my kernel.org tree
> back, should I continue to sign tags for pull-requests or was that
> just for external repos like github?

It's a good idea to to sign tags so that 3rd parties can verify your
pull requests if (God forbid) something like this were to happen
again.  I personally plan to use a tag like this: tytso-for-linus-20111026
(i.e., <username>-for-linus-<datestamp>).  It's not required, though.

						- Ted

  parent reply	other threads:[~2011-10-26 13:22 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-24 16:28 [GIT PULL] 9p changes fro merge window Eric Van Hensbergen
2011-10-25  7:25 ` Linus Torvalds
2011-10-25 20:14   ` Eric Van Hensbergen
2011-10-25 20:23     ` Eric Van Hensbergen
2011-10-25 20:46       ` Geert Uytterhoeven
2011-10-25 21:05         ` Eric Van Hensbergen
2011-10-26 12:28     ` Linus Torvalds
2011-10-26 12:48       ` Eric Van Hensbergen
2011-10-26 12:58         ` Linus Torvalds
2011-10-26 13:57           ` Eric Van Hensbergen
2011-10-26 14:05           ` Geert Uytterhoeven
2011-10-26 13:00         ` Pekka Enberg
2011-10-26 13:04           ` Pekka Enberg
2011-10-26 13:22         ` Ted Ts'o [this message]
2011-10-25 21:16 ` [GIT PULL] [Attempt #2] " Eric Van Hensbergen

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=20111026132253.GW31921@thunk.org \
    --to=tytso@mit.edu \
    --cc=ericvh@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=v9fs-developer@lists.sourceforge.net \
    /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.