Re: Feature freeze progress report

Dave,

> 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 
interface.  

> 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.

If many people are going to block on using a web tool for submitting new 
versions of a patch, claiming responsibility for review, etc., though, then 
we should probably abandon this discussion right here. No new tool is going 
to work if we have people who won't make any changes at all in their work 
habits.

> Oh for sure. We could even do silly stuff like try to automatically
> determine if the patch is in diff -c format ;-)

No!  Dave, you're a real radical sometimes.  

-- 
Josh Berkus
PostgreSQL @ Sun
San Francisco