On Mon, Jan 26, 2009 at 6:07 PM, Gregory Stark <stark@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
