On Mon, Jan 26, 2009 at 6:07 PM, Gregory Stark <st...@enterprisedb.com> wrote: >> 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). > > I've considered maintaining such a repository a few times and dismissed it > when I realized how much work it would be to maintain.
I don't think it would be too bad if everyone were using git. And in fact, if people weren't using git, but we had some kind of a system that could (1) return a list of all of the current patches and (2) return for any given patch the message-ids of the messages wherein the various versions of the patch were submitted, it would be harder, but possibly managable. You might have trouble with really big patches creating lots of merge conflicts, but even if you just merged all the smaller patches into one tree and push it out for people to test against, that might still have some real value if a decent number of people did testing against that tree. I think that it would probably be pretty easy to write a webapp to replace the CommitFest web page that basically did the same thing but with a bit more structure around it - with database tables like "commitfest", "patch", "patch_version", "patch_comment", and "patch_review". I think I might even be willing to write such a webapp if someone would be willing to provide the infrastructure. The CommitFest web page was really useful this time around, but it's not conducive to any kind of automated pull. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
