On 10/31/14 7:21 AM, Ehsan Akhgari wrote:
On 2014-10-31 1:48 AM, Gregory Szorc wrote:
> Short of
switching the canonical repositories to Git, what do you need to be more
productive?
I actually don't advocate switching our canonical repos to Git in the
short term (I strongly believe that is a decision that we made
incorrectly when switching away from CVS, but git's windows support kind
of forced our hands, and the past is past.)
In the current world, there are enough hg and git users that I think
Mozilla should consider supporting both as first class citizens. The
proper way to do that would be deploying a git push server which
eliminates the need to do anything with hg on the client side.
I owe you an answer to the rest of your response (your response is
extremely insightful into a number of issues), but I wanted to address
this one first.
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. 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.
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."
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.
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.
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).
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.)
Unless a major decision is made, we're trending towards more complexity
on the server to support Git ingestion. 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.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
