Hidden Commits in 4.3

Durham Goode durham at fb.com
Thu Apr 13 23:04:48 UTC 2017



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.



More information about the Mercurial-devel mailing list