Craig Ringer wrote: > Hi all > > Now that it's becoming more common to post patch series, not just > standalone patches, it might be worth looking at how the CF app can > help manage them. > > Any ideas?
I agree that we don't consider this case at all currently and that it's causing some pain. MIME parsing is mind-boggling. Trying to figure out *one* patch file from an email is already pretty difficult. Trying to figure out more than one might be nightmarish. Maybe Magnus will contradict me and say it's trivial to do -- that'd be great. I don't have any great ideas for how to support this; I'd say it would be something like the CF entry has sub-entries one for each patch in the series, that can be closed independently. This probably involves surgery to the CF database and app which I'm not volunteering to write, however. Django-enabled contributors speak up now ... I think for the time being we should keep the single entry as "needs review" or whatever open state until there is nothing left in committable state, then close as "committed"; the parts that were not committed can be resent as a new series to a later CF. In the annotations section, add a link to the latest version each time it's posted, along with some indication of how many parts are left[1]. Perhaps if a part is committed and there's no new version submitted soon, also add an annotation to indicate that. [1] Do not, as I've seen some do in the past, delete the old annotations while adding new ones. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
