Hidden Commits in 4.3

[Pierre-Yves David]

TL;DR;

I had a productive video call with Siddharth Agarwal today. We should be 
careful to not block the current path for completing 
changeset-evolution, but they are way forward that would allow to make 
progress on upstreaming Facebook work and improving local workflow while 
avoiding introducing BC problematic to changeset-evolution completion.

I saw Ryan sent a longer an email on this thread. I'll check it up and 
reply with more details on these way forward. (that won't happen today)

(yes this TL;DR; is a bit long in itself).

On 04/12/2017 12:20 AM, Kevin Bullock wrote:
>>> It sounds like there are no objections to the immediate 'hg hide' proposal, and the only points of contention are around the expected future interactions between hiding and exchanged obsolete markers. Is that an accurate assessment?
>>
>> ¿I'm quite confused? how do you end up interpreting:
>>
>>   "this kills our ability to complete and ship changeset-evolution
>>    to all Mercurial user in the next year or two."
>>
>> as:
>>
>>   "there are no objections"?
>

> It's not at all clear to me that having a single changeset hiding mechanism in
> core prevents completing and shipping evolve. My understanding from discussion
> at the sprint is that obsolescence markers could be used as one source of
> hidden nodes, with no external change in behavior. Let's not engage in
> hyperbolic statements about the future of any given feature; let's discuss the
> tradeoffs of various approaches.

I'm trying to underline a reality here, not making hyperbolic statement. 
We currently have:

1) a prototype for evolve, successfully used by actual people. (to solve 
the target goal)
2) a Roadmap to smooth the rough edges and ship it to all users[1],
3) funding for that Roadmap,
4) available coder-s- to turn this funding into code (me and a colleague).

Items (3) and (4) above are new, and (finally!) make is possible to 
envision changeset-evolution being completed in a not so distant future. 
(I'm not aware of alternative plan to ship evolution)

There are proposals in this thread and related ones that breaks concept 
heavily relied on by changeset-evolution (eg: global state, monotic 
rewrite[3]), without providing alternative to the solutions these 
concepts bring.

Moving forward with simply breaking this pillar-concepts holding 
changeset-evolution blocks our path forward to complete and ship 
evolution. This moves us,
* from: "I know how to ship evolution and have the resource to do so"
* to: "I do not know how to ship evolution".

Since I'm not aware of any alternative plan to complete and 
ship-changeset evolution, that effectively kills our current ability to 
bring changeset-evolution to completion in the foreseeable future.


[1] https://www.mercurial-scm.org/wiki/CEDRoadMap
[2] recent activity in the evolve extension:
     * last 45 days: 286 new changesets,
     * full year before that: 188 new changesets.
[3] https://www.mercurial-scm.org/wiki/CEDConcept

As pointed in the TL;DR; I had a productive discussion with Siddharth 
Agarwal today. We see ways to move forward with upstreaming (yeah!) work 
from Facebook to improves rewrite related workflows while being careful 
about their impact on changeset evolution. In short some of the behavior 
variants Facebook needs could be kept outside of Mercurial core backward 
compatibility envelope (eg: with configuration) until we are sure we 
have a way to completing-evolution with them.

I'll follow up more on these way forward once I've catch up with the 
Ryan email that arrived while writing this one.

-- 
Pierre-Yves David