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