Hidden Commits in 4.3

[Denis Laxalde]

Durham Goode wrote:
> 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).
>

I think that exposing the feature to more users behind a config knob
might help moving forwards to more practical considerations, and
eventually let the opportunity to users missing abstract knowledge to
participate to the discussion (by "users", I mean: readers of this
thread or list in general, so probably not the whole community but more
than a handful of developers).