Patch frustration

Dominik Psenner dpsenner at gmail.com
Thu Jun 7 02:01:44 CDT 2012


>However, it is a bit of a pain to keep track of what has been reviewed
>and what not. We have this same problem in the TortoiseHg project so I
>don't think this is specific to the mercurial project. Once you have a
>certain number of submitted patches waiting for review it starts to
>get complex to keep track of which have been reviewed and which have
>not. I solve that problem by "starring" the patches on gmail but it is
>not a perfect solution at all.
>
>Even after a patch has been queued, you must find the original
>revision in your local clone and strip it which is a pain. In fact
>that was the main motivation that made me write the "matching" revset
>keyword. Perhaps if/when the obsolete concept lands it will be
>possible to use it to avoid or automate this step?

Hi,

Sorry if I jump into this discussion even though I'm usually a quiet reader
of the dev list. :-)

I believe too that automating this process could help a lot. But I rather
see that a patch repository could fit into this job description together
with an extension to review patches.

The patch repository can already keep track of patches and how they evolve.
If that extension could now allow people to add bookmarks on a patch like
"accepted", "pending" or "rejected" and allow people to write comments
inline to the patch and send mails to the list as appropriate. If one for
example "accepts" a patch it could respond to the original email saying
"queued, thanks".

Of course the workflow is quite complex and outlining all the requirements
could cause some headache, but I think the idea is a good one.

Cheers



More information about the Mercurial-devel mailing list