Hidden Commits in 4.3

[Kevin Bullock]

I'm not responding to any technical points in this e-mail; I only want to address the current tone of the discussion.

> On Apr 11, 2017, at 15:29, Pierre-Yves David <pierre-yves.david at ens-lyon.org> wrote:
> 
> On 04/11/2017 12:43 AM, Augie Fackler wrote:
> 
>> This briefly confuses *me* when I trip over it,
> >
>> and I've helped work out some of the design of the feature,
> 
> I'm sorry, but no. you did not helped work out some of the design of the feature. You have barely contributed code touching evolution and not contributed to its concept. You attended some meeting and discussion, that does not automatically makes you an evolution expert.

Please keep these discussions polite and focused. There's no need to minimize the time and effort that others, including Augie, have put into making evolve something that we, and all our users, can all live with.

>> 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.

As I read it, there is consensus, even violent agreement, that having a mechanism to hide changesets that is separate from (and at a lower level than) obsolescence markers is desirable for a wide variety of use cases.

As I read it, there is some agreement that this should be a single unified mechanism which evolve should also eventually use. How it should use it is not agreed-on. If there is a reason that a different internal mechanism is required (or preferable), we should discuss the specific reasons why that's the case.

We all share the goal of making Mercurial even more flexible while keeping it easy-to-use for a broad spectrum of users. Doing that is tricky, so it requires clear, focused discussion.

pacem in terris / мир / शान्ति / ‎‫سَلاَم‬ / 平和
Kevin R. Bullock