Re: 8.4 release planning

Ron Mayer <rm_pg@cheapcomplexdevices.com>

From: Ron Mayer <rm_pg@cheapcomplexdevices.com>
To: Gregory Stark <stark@enterprisedb.com>
Cc: Merlin Moncure <mmoncure@gmail.com>, Josh Berkus <josh@agliodbs.com>, "Joshua D. Drake" <jd@commandprompt.com>, Robert Haas <robertmhaas@gmail.com>, "Jonah H. Harris" <jonah.harris@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Simon Riggs <simon@2ndquadrant.com>, Bruce Momjian <bruce@momjian.us>, Bernd Helmle <mailings@oopsware.de>, Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org
Date: 2009-01-26T22:42:32Z
Lists: pgsql-hackers
Gregory Stark wrote:
> I think a lot of people weren't aware there was anybody testing this patch
> ...I wonder how many more people are trying it out?

I think I have an idea to improve this aspect for future commit fests.

For a long time at each of my workplaces I've been running a development
instance against CVS-HEAD just to make sure our software is more future-proof
against up-and-coming releases.   We run this system with -enable-debug, asserts,
etc, and accept that it's just a development system not expected to be totally
stable.

If it were just as easy for us to pull from a
  "all 'pending-patches' for-commit-fest-nov that pass regression tests"
branch, I'd happily pull from that instead.

I realize in the current system (emailed patches), this would be a horrible
pain to maintain such a branch; but perhaps some of the burden could be
pushed down to the patch submitters (asking them to merge their own changes
into this merged branch).   And I hate bringing up the version control
flame war again; but git really would make this easier.   If all patches
were on their own branches; the painful merges into this shared branch
would be rare, as the source control system would remember the painful
parts of the merges.