Re: [HACKERS] CF app and patch series

[Magnus Hagander]

On Thu, Sep 8, 2016 at 5:48 PM, Alvaro Herrera 
wrote:

> 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.
>

Nothing is ever trivial :)

Actually, the archives collect all attachments. And they're available in
the API there. But the commitfest app only keeps the first one.

So would it be trivial to collect more? Not really. Would it be
nightmarish? No, not that either.

So if we can figure out how to actually work it into the UI of the CF app,
it should certainly be doable to track multiple attachments.



> 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 ...
>

Yeah, that would require a bit more surgery. Not sure how to represent it
though, if those patches are all typically sent in the same mailthread.
Which I guess they are. Because then that thread would have to be attached
to all of those sub-entries, which would kind of defeat the purpose?

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Re: [HACKERS] CF app and patch series

[Alvaro Herrera]

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 Herrerahttp://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

[HACKERS] CF app and patch series

[Craig Ringer]

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? Especially since the patch series may not get committed all
in one go, but progressively rebased on top of the bits that did get
committed until it's all in?

Making one CF app entry for this doesn't work well. It's confusing,
spammy in terms of number of entries involved, confusing for potential
reviewers, and pretty useless unless each patch is independent of all
the others. In which case they shouldn't be a series in the first
place.

A "partly committed" status doesn't help much; it doesn't signal
whether the rest is waiting for author response, awaiting review after
revision, etc.

So far I've just not been flagging it committed at all until
everything is. Or creating new CF entries that are immediately set to
"committed" for each part that goes in. But neither seems ideal.

Ideas?

-- 
 Craig Ringer   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, 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