Josh Berkus wrote:
>> The reason for basing the system on email is simply that it minimises
>> the changes required in the community process. If it were entirely web
>> based, we'd have to change the way we all work to discuss patches in a
>> forum style, rather than a list style. I have a sneaking suspicion that
>> at least one of our most valued contributors might object to that.
> Hmmm, yeah, I can see. However, I think it's possible to separate the patch
> discussion from patch submission; that is, to submit/edit/update patch code
> through the interface, but to do the discussion either through e-mail or the
I'd just keep all discussion in email, no need to do that off the web.
As long as you can *read* all the references on the web.
>> As long as the patch were initially submitted through the web interface
>> so that it got assigned an ID, we could automatically track the initial,
>> and followup threads on any of the lists as long as the ID is retained
>> in the subject line.
> Yes, and any changes to the patch code itself, as well. My concern with
> making the tool e-mail centric is that, based on e-mail based tools I've
> worked with, I'm afraid that the tool will be clunky/buggy enough not to be
> an improvement over the current process -- too much of e-mail format is
> optional varies by MUA. If e-mail is limited to commentary, though, I don't
> see that as a problem. And, of course, it would be easy for the tool to send
> e-mail to pgsql-patches.
I believe that's what Dave is proposing. If we want to implement
something like "reviewer signoff" (which we'd at least eventually want
to do, IMHO), doing that through the web interface primarily (for a nice
"tally" table) is probably a good start - it's a lot easier than parsing
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster