Re: automating CF submissions (was xlog location arithmetic) - Mailing list pgsql-hackers
From | Greg Smith |
---|---|
Subject | Re: automating CF submissions (was xlog location arithmetic) |
Date | |
Msg-id | 4F14A3EE.8000402@2ndQuadrant.com Whole thread Raw |
In response to | Re: automating CF submissions (was xlog location arithmetic) (Josh Berkus <josh@agliodbs.com>) |
Responses |
Re: automating CF submissions (was xlog location arithmetic)
Re: automating CF submissions (was xlog location arithmetic) Re: automating CF submissions (was xlog location arithmetic) |
List | pgsql-hackers |
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
pgsql-hackers by date: