Re: Patch committers

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Patch committers
Date: 2009-11-16 01:32:35
Message-ID: 603c8f070911151732v655b5db5l2a7912137e1fa0ca@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Nov 15, 2009 at 8:08 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Magnus Hagander wrote:
>> On Sat, Nov 14, 2009 at 13:35, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> > On Sat, Nov 14, 2009 at 4:11 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>> >> How about we add specific feature(s) about tihs to the commitfest
>> >> management tool? Like the possibility to directly link a git
>> >> repo/branch with the patch?
>> >
>> > So two fields, one for the repo URL and one for the branch name?
>>
>> Yeah, I think that's it. It might actually be interesting to pull the
>> latest version date and make a note in the cf management stuff
>> automagically in case there the git repo has a more updated version
>> than the one that was submitted. I think that could be quite useful -
>> shouldn't be too hard to do, I think. Probably just a cron job that
>> updates a third col in the db?
>
> Can you get git to dynamically generate a tree diff via a URL?  That
> would be nice.  Extra points for a context diff.  ;-)

I dunno about the automated comment generation thing. Seems like it
could generate a lot of comment spam inside the app. Also, I'm not
sure if we really want to move away from the mailing list as the
primary way of sharing patches. One nice thing about having them on
the mailing list is that it is a permanent archive. Another is that
it it is a "push" mechanism - you don't have to go to the CommitFest
app and notice, hey, there are new patches here, or new versions of
existing patches. You just read your email and there they are.

I'm not averse to adding fields for repo and branch; that seems pretty
uncontroversial, since they'll be optional and those who don't want to
use them needn't. But I think the rest of this needs a bit more
thought. Just MHO, of course.

...Robert

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2009-11-16 01:35:30 Re: named parameters in SQL functions
Previous Message Andrew Dunstan 2009-11-16 01:22:20 Re: named parameters in SQL functions