Hidden Commits in 4.3
Pierre-Yves David
pierre-yves.david at ens-lyon.org
Thu Apr 13 17:37:54 EDT 2017
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.
*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.
--
Pierre-Yves David
More information about the Mercurial-devel
mailing list