Hidden Commits in 4.3

Augie Fackler raf at durin42.com
Thu Apr 20 23:29:30 EDT 2017


(So it’s not buried: Pierre-yves, I’d like to grab a 30 minute VC to get a summary of your thoughts on this, since I know you’ve spent a lot of time on this, assuming you can make time Friday (the 21st).)

> On Apr 20, 2017, at 7:37 PM, Sean Farley <sean at farley.io> wrote:
> 
>>> In my example above, once "hg undo" is upstreamed, we are able to build
>>> a variant without hash preservation[1] and ship that the user by default
>>> without delay.
>> 
>> I'm sure you don't mean it this way, but this sounds a lot like "let's 
>> ship my thing and we'll figure your thing out later". The moment evolve 
>> ships, it becomes a lot harder to make the types of changes I'm talking 
>> about (both from a user experience point of view and community 
>> momentum), so I'd rather have the discussion now while it's still 
>> possible to make important changes.  If we flipped the sentence around 
>> (ship mine, figure yours out later) I'm sure you wouldn't be happy with 
>> that outcome either.
> 
> For what it's worth, I did not read it that way. Also, I've tried to
> avoid this discussion (across all the various threads) because it has
> been draining.
> 
>>> On a general principle, decoupling implementation discussion from UI
>>> polishing is usually a win.
>> 
>> If we decoupled UI from implementation here, we'd just go ahead and ship 
>> "hg unhide" with hash preservation, since that's objectively the more 
>> intuitive UI for unhide. But since the implementation of the obsolete 
>> graph doesn't allow that UI, implementation therefore affects our 
>> discussion.
> 
> At first reading of this, I find this kind of hostile from Facebook. I'm
> sure you didn't mean it that way but eh.
> 
> I found it hard to reply to this thread because of all the different
> derailings. For every non-Facebook dev here, there are so many more
> Facebook devs to reply to. That is exhausting. *I* am exhausted.

Looking at the participant list on this message (including me), it’s more non-FB people than FB. That said, all of the following are true:

 * Facebook is employing a *ton* of people to work on their tooling, including Mercurial

 * They have a will to upstream some really great work they’ve done to improve the Mercurial user experience, with many hundreds of happy users to back up the utility of their offerings, which means we could be the benefactors of their large group

 * The community is generally being difficult about these offerings, reducing that will[0]

I’m pretty frustrated with how this has gone (both on this thread, and elsewhere). We’ve got *real wins* available, but the conversation has been so fraught and verbose that I have no sense of who wants what. I can be available for video chats most of tomorrow (the 21st, America/New_York "typical waking hours") if that’s of interest and people are willing. Could a couple of people jump in and help me make sense of the state of things (without adding to the book’s worth of email already on this topic).

Thanks,
Augie
(more below as well)

0: It’s not my intent to cast blame. There’s plenty to go around, and I’ll say I’ve not infrequently been a source of difficulty. It’s my belief that we should, as a community, do better at taking advantage of the large user bases that are offering us pre-tested innovative ideas, with contributions of engineering time to land complicated work in core. Every monster thread like this one reduces *everyone’s* willingness to participate in the community, including my own.

> I'd love to discuss the pro's and con's of these two ideas purely from a 
>> UX standpoint, but I haven't seen any concrete examples of situations 
>> where evolve is affected by this for us to have a tangible discussion 
>> around it. If we had a concrete example, we could more productively 
>> evaluate the pro's and con's of these ideas.
> 
> There's so much convolution in this thread. For instance, I think (fast)
> local hiding would be cool. A version of that is possible today and I've
> even had my hand at it:
> 
> https://bitbucket.org/seanfarley/hgremotenames/commits/69cda2b8353ab1b108ca120d08eb253941f9ae70?at=hideable
> 
> That's remarkably simple and having a bitmap (or whatever) api would be
> good.

Yes, I think we’re all agreed on that, and it should preferably land (someone’s time allowing) very soon after the freeze ends so we can experiment with it and roll it back if it’s painful.

> I'm surprised there has been so much misinformation and changing
> of the goal posts. For instance,
> 

[...]

> None of the above, in my mind, requires the unhiding / cycle business.
> To me, getting the above points in core first (just making the happy
> path working, basically) would be a win. If that's not the goal, then
> I'm not really enthused about your proposals.

I’m starting to think that the unhiding without changing revision hash is more ergonomically reasonable. But as I said above, I think that decision can wait until later. There are real wins in-hand now, and it’s my (probably uninformed?) opinion that we’d be fools to not take those wins. 



More information about the Mercurial-devel mailing list