[Reviewers] dropped a couple changesets and flushed the queue

Pierre-Yves David pierre-yves.david at ens-lyon.org
Thu Dec 15 20:40:13 UTC 2016



On 12/05/2016 05:04 PM, Augie Fackler wrote:
> On Dec 2, 2016, at 10:53 PM, Pierre-Yves David <pierre-yves.david at ens-lyon.org> wrote:
>
> [snip extensive discussion of circumstances about which we’re generally in violent agreement, which aren’t relevant to the broader policy discussion I was trying to have]
>
>> I did got time to spend on Mercurial until today, almost one week later.
>
> What level of time commitment should we be expecting from you, out of curiosity? It occurs to me I don’t really know how much we should be expecting.

That's a legitimate question, thanks for asking :)

TLDR: about 2 days a week starting next week or the one after that.

My current plan is to spend about 50% of my work week on paid stuff and 
the other half on more generic project stuff, I should be able to get to 
that state in the coming weeks. I've now (almost) a company and a couple 
contract (almost¹) signed for improving various part of Mercurial 
(including evolution!)

The second half of October was ridiculously filled with unexpected 
things (mostly bad one) and November was also mostly filled 
unpredictable events (mostly good one). Then I faced the wall of delayed 
paperwork that I had delayed. That wall is now mostly handled and I'm 
actively shoveling the rest of my backlog out of the way… but the heap 
is high (as my average latency of a week shows…). You should be able to 
tell when I'm back on a more normal schedule when evolve's patches will 
be taken care off and I'll be writing code. Thanks for all of you 
keeping the project running  ☺

>> About rational for dropping Mads patch
>> --------------------------------------
>>
>> My initial email amongst other thing contains two important data about
>> this.
>>
>> 1) a sort explanation of the reason why I dropped mads patch:
>>
>>>> Mads histedit series got dropped because it change existing behavior
>>>> in way inconsistent with rebase and potentially harmful for user
>>>> relying on backward compatibility.
>>
>> 2) an explicitly mention I had detailed explanation about these drops
>> coming on the public mailing list threads. Verbatim below:
>>
>>>> Long explanation for each drop are on the way on relevant thread. But
>> here is a short version:
>>
>> I do not see these two elements taken in account in the main part of
>> your email replying to mine. Your objection to the drop of Mads patch
>> does not make any mention of elements in the "short explanation" and
>> later in that paragraph you requested a long version I already said to
>> be on the way.
>>
>> I'm mentioning and highlighting this because this is becoming a recurring feeling that your reply does not takes in account important
>> elements of email you are replying to. If we leave this un-addressed this will evolve in a major issue.
>
> I didn’t ever say it was unreasonable to have dropped these patches. I just haven’t personally observed any attempt to contact me before discarding a patch I’ve queued, so I wanted to bring it up as a potential policy point for discussion.

Okay, So the important part here is a the last two lines. The one where 
I express that "I've the feeling that your reply does not takes in 
account important element of the email you are replying to". (the rest 
is context to explain what feeds this feeling).
Your reply does not contains anything about that. Instead it seems to 
focus on the question of "did you object to the drop", something barely 
mentioned in the above section. This is strengthening my feeling :-/


Now that the topic of "did you object to the drop" is open, it is 
probably worth poking at.

(requoting the part for clarity)

> I didn’t ever say it was unreasonable to have dropped these patches.
> I just haven’t personally observed any attempt to contact me before discarding a patch I’ve queued, so I wanted to bring it up as a potential policy point for discussion.

I'm sorry but this is definitely not how I read your initial reply. I 
triple checked before writing my previous reply, and I doubled checked 
again before writing this one. To me the opening part (quoted below), 
just read like "I don't see why this was reasonable, especially in 
regard with Mads latency".

>>> It was not clear to me that there was consensus that the changes here were bad - I agree it would have been better as two patches, but other than that what am I missing that makes this worth dropping? History indicates it’ll be weeks-to-never that Mads comes back to it and it’s a clear defect fix on the whole, so I’d have liked it to be clearer on the public review thread what’s wrong here

That part (above) is about 70% of the total message payload and came 
first. This two things alone probably guaranteed I received reply as 
"aggressive reaction to the drop" and not "just wanting to bring a 
policy point to discussion".

Let's take a wider perspective on my experience here. The project had a 
growing situation of pending stack stuck for over a week (I'm not 
blaming anyone for not tackling it sooner). I took a couple of valuable 
hours on a Sunday late night to look in details at the issue and tackled 
it (I'm not asking for a medal for tackling and I know all of you also 
put valuable time in that project (thanks!)). The one and only thing I 
get in return for the effort and time is an email that I perceive as 
mostly negative. That is discouraging :-(. The whole thing is quite 
unfortunate since you apparently "violently agreed" that the drop was an 
overall good move.
So I would advise to put extra effort in having a more positive tone in 
email. Having an overall positive email with a small part dedicated to a 
proposal for improvement is very different from an email containing 
mostly (perceived) negative content.
A short rephrasing of that feedback is "please try to balance 
positivish/negativish ration in your email to match your mind state).

To make it very clear, I don't bring this up to paint Augie badly and I 
trust he meant good. I'm spending time explaining all this because that 
as also been a recurring issues in our community (from various people 
and affecting various people) and a significant causes for my burn out 
earlier this year.

>> On policy around dropping patch
>> -------------------------------
>>
>> I agree that getting a green light from another reviewers before
>> dropping is a good thing. Ideally, you get the approval of reviewers who
>> initially push the change (and any additional reviewer who approved it).
>>
>> However I trust other reviewer to be thoughtful and flexible on that.
>> If there is a legitimate reason to bypass it after careful
>> consideration, they should got for it.
>
> Note that I agree in this case the patches should have been discarded, but would have appreciated even a cursory attempt to contact me and ask before doing so. It’s a bad feeling for me to have my review work discarded without me having a chance understand why or even know it’s about to happen.

Yes, I should have pinged you beforehand. I understand it could have 
been frustrating for you. I'll make my best to put more effort into that 
if such situation arise.

It is probably worth to note that your ban of all communications between 
us outside public channels, adds a significant barrier to communicating 
such notice. That was part of why I skipped prior-pinging and directly 
moved to drop + "notification email"

(Still would have been better to ping you beforehand instead of picking 
the easy option)

>> Dropping a patches is not a big deal, it is easy to requeue it as draft
>> on the top of the start and resume the discussion. Right
>> now, the main pain around dropping is our tooling.
>
> Is dropping any more complicated than a prune, stabilize and push at this point? (With a warning and/or helping hand to the contributor so they don’t lose their change)?

Yes, currently, the stabilization means changeset get rewritten and 
repushed. As a result:

1) dropping existing accept stamps on everything we touched,
2) implicitly accept everything we repushed.

The problems gets bigger as the stack above what we drop growth (in our 
case 92, but this become painful much sooner).

Cheer

-- 
Pierre-Yves David

[1] Legals discussion are the fun…



More information about the Reviewers mailing list