Hidden Commits in 4.3

[Pierre-Yves David]

On 04/14/2017 01:04 AM, Durham Goode wrote:
> On 4/13/17 2:37 PM, Pierre-Yves David wrote:
>> On 04/12/2017 04:23 PM, Ryan McElroy wrote:
>>> […]
>> *Practical example* (/simplified/):
>>
>>    Situation:
>>
>>      * Facebook has a useful: hg undo command.
>>      * Facebook cares about hg undo, preserving the hash,
>>      * this hash preservation conflict with current constraint of
>>        changeset-evolution.
>>
>>    Way forward:
>>
>>      * Facebook can upstream hg undo with hash preservation,
>>      * We introduces a variant that changes the hash and makes it
>>        available to all users with BC,
>>      * Facebook can set the config for hash preservation internally.
>>
>>    Result: the code is upstream, user has new feature and we can
>>    discuss hash preservation later.
>
> I think this example is missing the step where we discuss what we should
> ship to users. My goal is not to enable Facebook to have a feature (we
> already have these features), my goal is to create a good user
> experience for Mercurial users. If we do the config knob route, we must
> at some point have the discussion about what experience we want to give
> to users, before we actually ship it to them.
>
> So in your proposal, when will it become appropriate to have that
> discussion? And what can we do between now and then to make that
> discussion more productive? I think we're blocked on getting bits into
> the hands of users by default until then.

(note: I've purposely delay more "discussion" oriented part in my other 
email (that you also replied to) I'll reply to it too shortly after this 
one.)


In my example above, once "hg undo" is upstreamed, we are able to build 
a variant without hash preservation[1] and ship that the user by default 
without delay. Of course "hg undo" with hash salting is less nice than 
"hg undo" with hash preservation, but already much better than no "hg 
undo" at all.


To generalize, I've already heard about multiple interesting UI bits 
from Facebook that the community could benefit from (undo, ui focused on 
evolving orphans, etc). These UI does not strictly depends on 
contentious bits like hash preservation.

We can upstream and ship these bit while discussing more complex UI 
changes on the side[2]. These discussion will be simpler since less work 
will be "blocked" behind their conclusion. Having the feature variants 
in the wild will also gather data on user response and help
other developer to be more familiar with the topic of the discussion.
On a general principle, decoupling implementation discussion from UI 
polishing is usually a win.


I know you have the experience of external user in mind. But having this 
code upstream will also directly benefit Facebook operations. Your 
maintenance load would be lowered (one of the topic at the past sprint) 
and your divergence from the Core UI reduced.

Cheers,

[1] (For the sake of this example, we assume a world with 
hash-preservation blocking changeset-evolution plans)

[2] while keeping that discussion focused.

-- 
Pierre-Yves David