Message-ID: <4F14A3EE.8000402@2ndQuadrant.com>
Date: Mon, 16 Jan 2012 17:25:50 -0500
From: Greg Smith <greg@2ndQuadrant.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111120 Icedove/3.1.16
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: Re: automating CF submissions (was xlog location arithmetic)
References: <4EDD97E5.8080201@timbira.com>
	<CAHGQGwFBF5D22cpw5gqXqLUDJLoJOfi_rc7BDg0==ekX4887tg@mail.gmail.com>
	<4F118D45.3060801@timbira.com> <4F122967.6070400@2ndQuadrant.com>
	<CABwTF4WpYyMy2Uk2j=oTB8RB-cf2EmRJ=wfiW2r3Gj5SBb+fAA@mail.gmail.com>
	<4F125998.5020204@2ndQuadrant.com> <4F148D29.7080504@agliodbs.com>
In-Reply-To: <4F148D29.7080504@agliodbs.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 01/16/2012 03:48 PM, Josh Berkus wrote:
> 3. Dig the messageID out of your sent mail.
>
> 4. Add a comment to the patch, type "Review" with the messageID, and
> ideally a short summary comment of the review.

This is the time consuming part that would benefit the most from some 
automation.  The message-id digging is an obvious sore spot, which is 
why I focused on improvements to eliminate so much of that first in my 
suggestions.  The problem is that we don't actually want every message 
sent to the list on a thread to appear on the CF summary, and writing 
that short summary content is an important step.

Archived messages deemed notable enough that someone linked the two are 
the only ones that appear in the patch history.  That makes it possible 
to come up to speed on the most interesting history points of a patch in 
a reasonable period of time--even if you missed the earlier discussion.  
I think any of the other alternatives we might adopt would end up 
associating all of the e-mail history around a patch.  That's the 
firehose, and spraying the CF app with it makes the whole thing a lot 
less useful.

I don't think this is an unsolvable area to improve.  It's been stuck 
behind the major postgresql.org site overhaul, which is done now.  
Adding some web service style APIs to probe the archives for message IDs 
by a) ancestor and b) author would make it possible to sand off a whole 
lot of rough edges here.  While it's annoying in its current form, doing 
all my work based on message IDs has been a huge improvement over the 
old approach, where URLs into the archives were date based and not 
always permanent.

> I'll also point out that the process for *applying* a patch, if you
> don't subscribe to hackers and keep archives around on your personal
> machine for months, is also very cumbersome and error-prone.  Copy and
> paste from a web page?  Really?

The most reasonable answer to this is for people to publish a git repo 
URL in addition to the "official" submission of changes to the list in 
patch form.  And momentum toward doing that just keeps going up, even 
among longer term contributors who weren't git advocates at all a year 
during the transition.  I nudged Simon that way and he's pushing 
branches for major patches but not small ones yet, it looks like Andrew 
fully embraced bitbucket recently, etc.

We're 16 months into git adoption.  I'm pretty happy with how well 
that's going.  We don't need to add infrastructure to enable people to 
push code to github and link to their branch comparison repo viewer as a 
way to view the patch; that's already available to anyone who wants is.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com