Hidden Commits in 4.3

[Durham Goode]

I respond below, but I believe Jun has sent you a innovative proposal 
that may solve both of our needs and render this discussion irrelevant. 
So take a look at his proposal at your earliest convenience, since it 
may let us put this behind us.

On 4/18/17 11:03 AM, Pierre-Yves David wrote:
> 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.

I'm sure you don't mean it this way, but this sounds a lot like "let's 
ship my thing and we'll figure your thing out later". The moment evolve 
ships, it becomes a lot harder to make the types of changes I'm talking 
about (both from a user experience point of view and community 
momentum), so I'd rather have the discussion now while it's still 
possible to make important changes.  If we flipped the sentence around 
(ship mine, figure yours out later) I'm sure you wouldn't be happy with 
that outcome either.

> On a general principle, decoupling implementation discussion from UI
> polishing is usually a win.

If we decoupled UI from implementation here, we'd just go ahead and ship 
"hg unhide" with hash preservation, since that's objectively the more 
intuitive UI for unhide. But since the implementation of the obsolete 
graph doesn't allow that UI, implementation therefore affects our 
discussion.

I'd love to discuss the pro's and con's of these two ideas purely from a 
UX standpoint, but I haven't seen any concrete examples of situations 
where evolve is affected by this for us to have a tangible discussion 
around it. If we had a concrete example, we could more productively 
evaluate the pro's and con's of these ideas.

Given that evolve has been around for years and people still aren't able 
to reason about concrete examples in these discussions, I don't think 
the strategy of 'give it more time' is going to help move this 
discussion forward.