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.