All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Mike Marshall <hubcap@omnibond.com>
Cc: Martin Brandenburg <martin@omnibond.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [git pull] orangefs bugfixes for rc2
Date: Thu, 31 Mar 2016 17:11:01 -0500	[thread overview]
Message-ID: <CA+55aFz3iiBib0dGKXKi3mRBWyK8AK1WwajCAYN321aZ5X1jFA@mail.gmail.com> (raw)
In-Reply-To: <CAOg9mSQjSV6eT7OiNV_GrM5bHE-JeSqyBWTdVxd-DxUuDjdb_g@mail.gmail.com>

On Thu, Mar 31, 2016 at 4:06 PM, Mike Marshall <hubcap@omnibond.com> wrote:
> sorry to follow up my own post... perhaps we should
> point our pull requests at Al and base them on one
> of Al's trees? I'm sure all this should be easy, we're
> just clumsy 'cause we're new...

No, for stuff that is entirely internal to a filesystem, the
filesystem maintainers should preferably strive to be as independent
of all other trees as possible.

That means that the base you use should generally be either your own
previous top-of-tree (ie without any back-merges from me or other
trees at all: so your branch only contains your own work), or if it
ends up being more convenient some "well-defined" general release (ie
a major release like 4.5, or a later rc like rc4+ that is starting to
be considered reasonably stable).

For bug-fix pulls, the best base tends to be your own tree that you
asked me to pull during the merge window, while then "new development
for the next version" might be some known base.

Of course, since orangefs just got merged, you can't use 4.5 as a
base, but then going forward when you start doing development that you
expect to be merged for 4.7, you might want to use 4.6 as a base for
that.

Right now, using rc1 as a base for fixes would also be reasonable,
exactly because you can't use any older release. But in general it's
best to try to have better starting points than rc1 (or worse yet,
some "random daily point from Linus") which may have undiscovered bugs
etc.

         Linus

  reply	other threads:[~2016-03-31 22:11 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-31 16:17 [git pull] orangefs bugfixes for rc2 Martin Brandenburg
2016-03-31 19:27 ` Linus Torvalds
2016-03-31 21:01   ` Mike Marshall
2016-03-31 21:06     ` Mike Marshall
2016-03-31 22:11       ` Linus Torvalds [this message]
2016-03-31 22:59       ` Al Viro
2016-04-01  1:19     ` Theodore Ts'o
2016-04-01 19:49   ` Martin Brandenburg
2016-04-01 22:35     ` Linus Torvalds
2016-04-01 23:29       ` Mike Marshall
2016-04-01 23:23     ` Joe Perches
2016-04-02  1:32       ` Martin Brandenburg

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=CA+55aFz3iiBib0dGKXKi3mRBWyK8AK1WwajCAYN321aZ5X1jFA@mail.gmail.com \
    --to=torvalds@linux-foundation.org \
    --cc=hubcap@omnibond.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin@omnibond.com \
    --cc=viro@zeniv.linux.org.uk \
    /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.