[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: [patch 04/16] Without this patch at least IBM VisualAge C 5.0
From:       Jeff King <peff () peff ! net>
Date:       2010-04-28 16:23:24
Message-ID: 20100428162324.GB7527 () coredump ! intra ! peff ! net
[Download RAW message or body]

On Wed, Apr 28, 2010 at 10:55:54AM +0200, Tor Arntsen wrote:

> >> The patch is against master. Are we supposed to make patches against
> >> master or maint? (I thought I saw the latter somewhere. I'm pretty
> >> new in here though..)
> [...]
> Ok. That would correspond to master from git anyway. I make my patches
> against a git checkout, and I was just throwing out the question to
> the general audience, for my own knowledge.

The answer is that you should base your patch on whatever is the best
place for Junio to apply it. :)

For new feature work that will go into the next 3-number release (e.g.,
1.7.1), that should generally just go on 'master'.

For bugfixes that will be part of stable release (e.g., 1.7.0.7), they
should generally go right on top of the commit introducing the bug, and
can then be merged into whichever versions exhibit the bug. If it's not
a bugfix but rather a documentation or portability fix that should go to
maint, and doesn't necessarily have a specific commit to based on,
building on 'maint' is probably OK, which would be appropriate for the
next stable release. There is some benefit to going farther back if the
fix should be merged to multiple maint tracks (e.g., both 1.6.6.x and
1.7.0.x). I'm not sure how Junio decides which maint releases are "too
old" to care about.

It's almost never a good idea to base work on "next" as a whole.  It is
appropriate to base work on commits on a topic that is _in_ next, but
only if you are building on to that topic. Otherwise, we try to keep
topics independent (by building them on "master") so that they can be
merged independently as they mature.

For this particular patch set, "master" is probably a good starting
point. Portability fixes can often go to maint as described above, but
this particular patchset is more like feature work. It's big and
invasive, and it is not about fixing minor portability issues introduced
by recent commits, but rather is about porting to many brand new
platforms.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]