Patch frustration

[Angel Ezquerra]

On Thu, Jun 7, 2012 at 7:58 AM, Bryan O'Sullivan <bos at serpentine.com> wrote:
> On Wed, Jun 6, 2012 at 7:22 PM, Matt Mackall <mpm at selenic.com> wrote:
>>
>>
>> I've never stopped taking patches in crew. Took patches in crew from
>> Adrian via Mads in just the last few days. But I'd prefer if someone
>> reviewed things in some fashion before they showed up in crew as it's
>> always a nuisance to do backouts.
>
>
> OK. I'll see if my ssh key still works for crew (Thomas, na du!) and start
> funneling some stuff through. But anything that I consider taking I'll ack
> here first.
>
>> If you want lower latency, you have to let the queue empty, folks.
>
>
> Good problem to have.

I don't contribute much to mercurial, but personally I don't mind the
latency between submitting a patch and getting a review (although it
would obviously be better if it was lower). Given the number of
patches that are sent here I think it is quite reasonable.

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?

I wonder if it would be possible to have a bot track the mailing list
and automatically generate a web page listing the patches that are
pending a review (i.e. have received no replies on the list) and those
that have been reviewed. The bot could even keep track of those
patches that have been queued, since there is usually a "queued,
thanks" message for them. If the page provided some filtering
capabilities it could be easy to track the state of your own patches.
It could even show links to the corresponding mailing list threads.

The tricky part would be keeping track of those that are dropped or
those that must wait for the end of a code freeze, etc. Maybe a simple
rule such as removing patches from the review list automatically after
a given amount of time would solve that.

I don't know how practical this would be, but I think there must be a
way to make the whole process a little easier, not only for mercurial,
but for similar projects, while keeping the email based workflow that
Matt wants.

Angel