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.
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
