DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	b=Aa4F5kKq89sOjhVfNdZMDey17EHQdmcGd7R+8QhGw8mVBh5Cqe3e8nLa0xbt5vq047
	BmOy+05QhL/nUogwRK5frGb1kSEMv+CQRQ3/TId64HHwG2o2ptvXxli9GJ6owNYeviqg
	iIATrrn81Ybyrjnu6EdM72h8TGwrs8Lsphsww=
MIME-Version: 1.0
In-Reply-To: <2871.1244209112@sss.pgh.pa.us>
References: <20090526144812.GC15213@yugib.highrise.ca>
	<20090603131004.12934iyrr4f7rlsc@mail.bluegap.ch>
	<4136ffa0906030508i2971790dk54a8203ee03ed196@mail.gmail.com>
	<4A266A56.2020703@anarazel.de>
	<4136ffa0906030701x200bf0e4o4c77fa3239062ca5@mail.gmail.com>
	<e51f66da0906030720u33d72d05y14ea5ce002cbaf1e@mail.gmail.com>
	<20090604114610.808217tbogts0noi@mail.bluegap.ch>
	<4A283A8D.8030600@cheapcomplexdevices.com>
	<20090605090514.11712ntlvhi2deay@mail.bluegap.ch>
	<2871.1244209112@sss.pgh.pa.us>
Date: Fri, 5 Jun 2009 11:29:30 -0400
Message-ID: <603c8f070906050829m1eaaa969tff7ca85d04018c5a@mail.gmail.com>
Subject: Re: PostgreSQL Developer meeting minutes up
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Markus Wanner <markus@bluegap.ch>,
	Ron Mayer <rm_pg@cheapcomplexdevices.com>,
	Marko Kreen <markokr@gmail.com>, Greg Stark <stark@enterprisedb.com>,
	Andres Freund <andres@anarazel.de>, Aidan Van Dyk <aidan@highrise.ca>,
	Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>,
	Magnus Hagander <magnus@hagander.net>,
	Andrew Dunstan <andrew@dunslane.net>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Fri, Jun 5, 2009 at 9:38 AM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> "Markus Wanner" <markus@bluegap.ch> writes:
>> Note that a requirement for daggy fixes is that "the bug is fixed
>> close to the point where it was introduced". So fixing it on the
>> oldest stable branch that introduced a bug instead of fixing it on
>> HEAD and then back-porting would certainly be a step into the right
>> direction.
>
> I think it's already been made crystal clear that the people who
> actually do this work don't do it that way, and are uninterested in
> allowing their tools to force them to do it that way. =A0Patching from
> HEAD back works better for us for a number of reasons, the main one
> being that HEAD is the version of the code that's most "swapped into"
> our awareness.
>
> However, so long as we can have a separate working copy per branch,
> I see no problem with preparing all the versions of a patch and then
> committing them back-to-front. =A0What I'm not clear about is the
> mechanics for doing that. =A0Would someone explain exactly what the
> steps should be to produce the nicest-looking git history?

I'm sure someone is going to come in here and again recommend merging,
but I'm going to again recommend not merging.  Cherry-picking is the
way to go here.  Or just commit to each branch completely separately
with the same commit message; cherry-pick at least IMO is just a
convenience to help you attempt to apply the patch to a different
branch.

The way you're using commit messages to construct the release notes
really puts a limits on what the history has to look like.  I think it
would be good to find a better way to generate release notes that
isn't quite so dependent on having a very tight history, but even if
we do that I think in this particular situation cherry-picking is
going to be less work for the committers than any of the other options
that have been proposed.

...Robert