On 2014-10-31 12:51 PM, Gregory Szorc wrote:
As has been said on this list before, switching canonical to Git just
isn't going to happen. Valid reasons have been given before. But here's
a new one: we don't need to.
I think it's fair to say that the pain point for Firefox Git developers
*today* is that they need to run Mercurial locally. That introduces
overhead, new commands to learn and run, etc. As you mention, setting up
a server to receive Git data/pushes eliminates a lot of problems.
I thought about deploying something like Fog Creek's Kiln (software that
speaks the wire protocol for both Mercurial and Git and does conversion
behind the scenes). However, the more I think about it, the more this
idea terrifies me.
FWIW I think that solution is needlessly complicated.
> The moment you do that you are catering to the lowest
common denominator (or at least it becomes easy to fall into that trap).
This likely penalizes Mercurial users because we can't extend Mercurial
as much and thus can't capture as many productivity wins.
I do think that we should continue to cater towards the lowest common
denominator. And what I mean by that is to not use hg features which
will be impossible to support in git and vice versa. But I'm not sure
what things you were talking about here specifically. Having
discussions about the lowest common denominator in the abstract is hard!
All problems in computer science can be solved by another level of
indirection. The problem here is that Git users need to push to the
canonical Mercurial repositories (inbound, try, etc). You will be
hearing me say this a lot in the months ahead, but "Autoland changes
everything."
I don't understand how. Doesn't Autoland still require you to push your
changes somewhere? If that somewhere is an hg repo we're back to square
one.
With Autoland in place, there is a level of indirection between the user
and landing: a landing queue. In my utopian end state for Autoland, no
user - whether they use Git or even Mercurial - are pushing directly to
the canonical repositories. Only the Autoland agent performs that role.
FWIW I think that's a bit too eutopian. I have no hopes of eliminating
all of the need for pushing stuff manually. "Land this thing at some
point in the near future" is a very common use case but it's far from
being the only one.
Suddenly the publishing workflow becomes unidirectional and this whole
syncing problem with Hg<->Git SHA-1 maps becomes abstracted away into
the implementation of Autoland. We can stand up Git servers to allow Git
native ingestion, without burdening Git users with the knowledge,
overhead, or cognitive dissonance of Mercurial.
Not sure if I follow. Are you suggesting that git users push to their
own vanilla git server, and then autoland comes around some time later,
converts that into hg, and tries to transplant the result? Why is that
better than just having a git server that pushes to an hg server before
accepting a push? That seems to both address the use case of pushing to
Autoland's hg repo, and also the use cases that do not involve Autoland.
That end state would solve a lot of problems. But a few remain. Notably,
collaboration between Mercurial and Git users would still be problematic
(it likely always will be).
Yes, agreed.
It also means the server-side infrastructure becomes more complex and
harder to maintain. To achieve the tight cohesion necessary to present a
fully optimized and seamless workflow, all these services likely need to
be running as part of the same logical system, sharing the same
underlying data store, without syncing being a major issue. Do I think
this is the right and inevitable solution? Yes, I do. Ideal, no. (Ideal
would be to support one system - and tell the users of the other to take
a hike. If I had my way, that one system would be Mercurial because it
is easier to extend and can lead to better productivity. But short of a
mandate that makes a lot of people upset and has extremely high costs to
implement, this ideal isn't going to happen.)
Since you keep mentioning this (and *without meaning to start a flame
war*), let this be on the record that I think mercurial's extensibility
etc don't really matter for a user of the VCS, unless they work in a
very specialized environment (such as the big silicon valley tech
companies that have used hg in the past few years). Productivity is
subjective, and not an objective property of either git or mercurial.
The reason I and others go through this pain right now to avoid having
to use hg more is increased productivity. So, I'd appreciate if you
didn't make it sounds like mercurial is all about user productivity and
git isn't. :-)
Unless a major decision is made, we're trending towards more complexity
on the server to support Git ingestion.
Are we though? Cause for the past recent years, our approach towards
git users has been very close to "take a hike". Is there now a push
towards treating them better? (Genuinely asking, since I haven't heard
anything about an organizational drive towards treating git users better
recently.)
> Again, I think that is the
correct outcome. A problem is we don't have the resources to instantly
make that happen. As much as I want to have a flag day where Try is
fixed and Git users get native ingestion, it isn't going to happen at
the same time. We have a pressing need to fix Try. We need to fix Try
first, *then* make the Git users happier [through native ingestion].
And, doing Git hosting right involves merging (or at least strongly
coordinating) a lot of systems managed by different groups
(hg.mozilla.org, git.mozilla.org, vcs2vcs, autoland, mozreview, release
automation, etc). Fortunately, recent org changes have made that easier
(this should all fall under Laura Thomson), so it isn't the pipe dream
it once was.
I *think* the Git users will eventually be able to eat cake. But it may
take a bit. It's not going to happen overnight. It certainly isn't going
to happen before the replacement Try infrastructure is deployed. What
I'm looking for is a path forward that placates the Git crowd until we
have the organizational will and resources to tackle Git ingestion. If
that means I or someone else must write Git tools to support the new
systems, so be it. I'll happily choose that outcome over bloating scope
to cover increased server complexity in the short term. I just need to
be sure the solution is tolerable by Git users.
I think everyone understand that as a git user, they're a second class
citizen at best, so this won't be surprising. But I'd like to talk
about two specific points:
1. Are the changes that you're planning to make to the try server
inherently incompatible with git? An example of such an incompatibility
would be for example changing the wire format of the protocol to send in
data that is only available on the client and not transmittable through
git push.
2. What if anything should we do differently in the mean time?
Both of these questions would be easier to answer if you explain your
plans in more detail. :-)
Cheers,
Ehsan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
