[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