Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id 5ACB42E0068 for ; Fri, 4 Apr 2008 23:53:41 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 00445-09 for ; Fri, 4 Apr 2008 23:53:37 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from lists.commandprompt.com (host-159.commandprompt.net [207.173.203.159]) by developer.postgresql.org (Postfix) with ESMTP id 379642E0064 for ; Fri, 4 Apr 2008 23:53:37 -0300 (ADT) Received: from localhost (or-69-34-217-90.sta.embarqhsd.net [69.34.217.90]) (authenticated bits=0) by lists.commandprompt.com (8.13.8/8.13.8) with ESMTP id m352rxVF028654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Apr 2008 19:54:00 -0700 Date: Fri, 4 Apr 2008 19:55:58 -0700 From: "Joshua D. Drake" To: Tom Lane Cc: Bruce Momjian , Alvaro Herrera , Gregory Stark , Greg Smith , Pg Hackers Subject: Re: Patch queue -> wiki Message-ID: <20080404195558.4753580c@commandprompt.com> In-Reply-To: <27542.1207363037@sss.pgh.pa.us> References: <200804050114.m351E6900485@momjian.us> <27542.1207363037@sss.pgh.pa.us> Organization: Command Prompt, Inc. X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.0; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (lists.commandprompt.com [207.173.203.159]); Fri, 04 Apr 2008 19:54:00 -0700 (PDT) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200804/325 X-Sequence-Number: 116418 On Fri, 04 Apr 2008 22:37:17 -0400 Tom Lane wrote: > Bruce Momjian 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 add merge, 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 have a 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