Re: Patch queue -> wiki - Mailing list pgsql-hackers

On Fri, 04 Apr 2008 22:37:17 -0400
Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Bruce Momjian <bruce@momjian.us> writes:
> > I think ultimately we are going to have to remove the patches email
> > list and require patch submitters to add their patches to a patch
> > tracker. 
> 
> That's outright silly.  The email list and archives are a critical
> part of what we do, because they provide a historical record.  Nor is
> raising the bar for submitting patches a good idea.

Command Prompt uses a tool that allows us to transform emails to
tickets via Trac. It is not perfect but it works for us. It has two
modes, autocreate and not.

With autocreate every email that hits the list is automatically a
ticket. 

Without autocreate you must put: @trac create into the message body for
a ticket to be created.

The flow works like this:

email testlist@lists.commandprompt.com email->tracman->trac->list

Where the email is intercepted by tracman, which reads the email to see
if it is already a ticket, if so the ticket within trac gets updated
and then the email is released to the listserv.

If the email is not a ticket (and autocreate is on), tracman intercepts
the email, creates a ticket in trac, rewrites the subject of the email
to have the ticket number and releases the ticket to the list serv.

Further if you want to update a ticket via the web interface to trac
you can and it will also correctly deal with list traffic.

The following commands are supported:

@trac create : creates a ticket

@trac assign : takes a second argument which allows you to assign to a
person

@trac close : closes a ticket

In the current infrastructure the missing things for CMDs workflow is:

1. Attachments if sent via email stay a part of the email, if they are
attached via trac, they stay part of the ticket. So you can actually
have two sources of attachments.

2. There is no merge capability. At some point we want to be able to
say this:

@trac merge 27

And the email getting intercepted would automatically merge into ticket
27.

I am not saying we should use this for the project. I am not even
saying it is a good tool for the project. I am saying that if some
hackers want to play with the idea for a patch queue using it, I would
be happy to provide resource to that. I would also be willing to
provide resources to make reasonable modifications to tracman to allow
it to work for our environment.

The key to this is, with very little effort we would have:
* Proper attachment capability (gets saved into postgresql) * A single source for communication about patches  * If we
addmerge, we can even forward an email from hackers that is
 
relevant and merge it into a patch (which is a ticket).* Always see what the latest patch is because the ticket will
havea
 
patch and timestamp associated with when the patch came in* Have a wiki that can associate explicitly with the
tickets/patches

And if we ever change to mercurial, svn or git, we can use Trac as the
front end and not only have a wiki,tickets,patches but also source tree
references including changesets etc...

Sincerely,

Joshua D. Drake







-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate