Excerpts from Tom Lane's message of jue abr 12 00:49:38 -0300 2012:
> At the other end of the scale, I think it's true that the CF app could
> be more helpful than it is for tracking the state of complex patches.
> I don't really have any concrete suggestions, other than that I've
> seen far too many cases where the latest version of a patch was not
> linked into the CF entry. Somehow we've got to make that more robust.
> Maybe the answer is to tie things more directly into git workflows,
> though I'm not sure about details. I am concerned about losing
> traceability of submissions if all that ever shows up in the list
> archives is a URL.
Two suggestions:
1. it might be convenient to have the patch author attach a suggested
commit message to the patch entry in the commifest site. Would save
some jiffies for the trivial patch case, I hope.
2. instead of just sending a URL to the list, maybe it'd be better if
the patch is uploaded to the CF site, and the CF site sends it to
pgsql-hackers for archival and reference, with appropriate In-Reply-To
headers so that it is appropriately linked to the thread. But since
the patch has been registered into the CF, the site can additionally
present a link to download the patch directly instead of sending you to
the archives. So redundant storage, for convenience.
(Alternatively, the CF app could reach into archives to grab the patch
file. With some appropriate ajaxy stuff this shouldn't be particularly
hard.)
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
