On 4/13/17 2:37 PM, Pierre-Yves David wrote:
On 04/12/2017 04:23 PM, Ryan McElroy wrote:
I think the next step is for the community to officially figure out if
this is a good direction to go in, however that happens.
I had productive face to face discussion with multiple people in the
past couple a day. Let us put all technical details aside and look at
the situation at the high level.
The current tentacular discussions are the *gathering of three different
goals*:
* *upstreaming* more of Facebook work (yeah!),
* *completing changeset evolution* and shipping it to all users,
* *shipping improvement to users* sooner than later.
All these goals are *important, good, realistic *and*compatible* if done
carefully.
They interact with each others, so we have to make sure we *achieves
each goal without blocking the others*. Something not guaranteed so far
in the current discussions.
So what is our way forward in practice? After discussions with Ryan,
Siddharth and Gregory, I think *we could use the following principle*:
When If *someone raise concerns* about the impact of a feature on
other goals, get the feature in, but *keep it under a config flag
while we resolve the situation* in one of the following ways:
* more thinking *lift the concerns*,
* a *small variant* that can be on by default is introduced,
* an *equivalent, alternative featured be *on by default in added,
* an alternative path to the concepts is found that.
As a result:
* *Facebook can upstream and share code* more easily. Having to live
with a config knob for a while is not a big deal for them,
* The surface on which we guarantee backward compatibility *leaves the
path to complete changeset-evolution open*,
* In many cases, *community can take advantage of the upstreamed code*
to offer better capability to the user with just an extra bit of
code to implement a small variant,
* As a bonus we can experiment with alternative path and get data
about them.
I'm happy to introduce the initial version of this under a config flag.
However, I think this just means we delay having this same discussion to
a later date. And it's not clear how having that config flag for some
time will improve people's understanding to make the discussion more
productive (since presumably the community isn't using the flag).
*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.
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
