From: | Greg Smith <greg(at)2ndQuadrant(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: automating CF submissions (was xlog location arithmetic) |
Date: | 2012-01-16 22:25:50 |
Message-ID: | 4F14A3EE.8000402@2ndQuadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2012-01-16 22:28:56 | Re: Review: Non-inheritable check constraints |
Previous Message | Alvaro Herrera | 2012-01-16 22:08:09 | Re: automating CF submissions (was xlog location arithmetic) |