[PATCH 5 of 6 V3] hgweb: blacklist heavyweight revset functions in hgweb search

Alexander Plavin alexander at plav.in
Sat Sep 14 03:02:40 CDT 2013



14.09.2013, 02:15, "Matt Mackall" <mpm at selenic.com>:
>>>  Recommended reading:
>>>
>>>  http://mercurial.selenic.com/wiki/ContributingChanges#Flow_control
>>>  http://www.selenic.com/inbox
>>  I've read this already, and my submissions satisfy almost all of the
>>  points at #Flow_control.
>
> Then you've completely failed to understand what's written there. Let's
> quote Wikipedia:
>
> "In data communications, flow control is the process of managing the
> rate of data transmission between two nodes to prevent a fast sender
> from overwhelming a slow receiver."
>
> Click here:
>
> http://www.selenic.com/inbox
>
> See that second number? That's the number of patches still waiting in my
> inbox. See how it's MUCH greater than 100? See the third number? That's
> roughly the number of days behind on email I am. Kindly slow way the
> hell down so I can catch up. Consider going all the way down to one
> unacknowledged patch at a time.

By writing "my submissions satisfy almost all of the points" I really meant "almost all", not just "all". Actually, all points are impossible to satisfy: I can't simultaneously reply with new versions of patches quickly AND slow down while the number of patches at http://www.selenic.com/inbox is >100 (as I rememeber, during the last week or more it was >100 all the time, throught I may be wrong here). So, as I can't satisfy all the points, I've chosen a subset of them, and according to your messages here I had to chose another subset. And still not quite sure, what exactly is 'slow down' here? Send no more than N patches (and K emails?) per M days while the amount of patches is >100? Or something else?

By the way, the previous version of http://mercurial.selenic.com/wiki/ContributingChanges (about just a month ago) was much more loyal to contributors.

>
>>   For example, there are only 8 my patches which are marked with
>>  'Action Required' at patchwork, and it doesn't seem a great number.
>
> Patchwork (as the first page says) is irrelevant. It is of practically
> no use to me in particular, since I'm already using my inbox to track
> patches. It actually makes what I do MORE WORK by adding a whole second
> system to track what's already in my inbox and since I can't do email
> reviews from patchwork, I can't ditch my inbox.

The whole situation isn't clear for contributors, as we can see which patches need review at patchwork but can't see those that need review at your inbox. The amount of patches at http://www.selenic.com/inbox is always greater than at patchwork, so I think there are just old versions of patches which don't need reviewing, and only discussion related to them can be of some use.

I'd note that while the whole system of reviewing by email looks like the best way for those who got used to it during years, it's not so for other people who already used special patchtracking systems. Even from this part of your message it seems to me that it would be much better for the whole reviewing process if there was the ability to unite an old and new version of a patch/series in one place, with the discussion together. And yes, I know that you all can name a lot of advantages of plain old email reviewing, here is just a note.

>
> --
> Mathematics is the supreme nostalgia of our time.

I want to say once again here, that it would be better if you told not what NOT to do (like 'don't send many new patches ...'), but what to do actually (like 'send no more than N patches (and K emails?) per M days while the amount of patches is >100'). Now it's not fully clear, at least for me.


More information about the Mercurial-devel mailing list