[TL;DR, I think we need to embrace git in addition to hg for
Firefox/Gecko hacking, what do you think?]
Hello everyone,
The question of whether Mozilla engineering should embrace git usage for
Firefox/Gecko development has come up a number of times already in
various contexts, and I think it's time to have a serious discussion
about this.
To me, this question has already been answered. Git is already a reality
at Mozilla:
1. Git is in use exclusively for some of our significant projects (B2G,
Gaia, Rust, Servo, etc)
2. Lots of Gecko hackers use git for their work on mozilla-central,
through various conversions from hg to git.
What we're really talking about is whether we should embrace git for
Firefox/Gecko development in mozilla-central.
IMO, the benefits for embracing git are:
* Simplified on-boarding, most of our newcomers come to us
knowing git (thanks to Github etc), few know hg.
* We already mirror hg to git (in more ways than one), and
git is already a necessary part of most of our lives.
Having one true git repository would simplify developers'
lives.
* Developers can use git branches. They just work,
and they're a good alternative to patch queues.
* Developers can benefit from the better merge algorithms
used by git.
* Easier collaboration through shared branches.
* We could have full history in git, including all of hg
and CVS history since 1998!
* Git works well with Github, even though we're not switching
to Github as the ultimate source of truth (more on that below).
Some of the known issues with embracing git are:
* Performance of git on windows is sub-optimal (we're
already working on it).
* Infrastructure changes needed...
So in other words, I think there's significant value in embracing git
and I think we should make it easier to hack on Gecko/Firefox with git.
I see two ways to do that:
1: Embrace both git and hg as a first class DVCS.
2: Switch wholesale to git.
Option 1 is where I personally think it's worth investing effort. It
means we'd need to set up an atomic bidirectional bridge between hg and
git (which I'm told is doable, and there are even commercial solutions
for this out there that may solve this for us). Assuming we solve the
bridge problem one way or another, it would give us all the benefits
listed above, plus developer tool choice, and we could roll this out
incrementally w/o the need to change all of our infrastructure at once.
I.e. our roll out could look something like this:
1. create a read only, official mozilla-central git mirror
2. add support for pushing to try with git and see the results in tbpl
3. update tbpl to show git revisions in addition to hg revisions
4. move to project branches, then inbound, then m-c, release branches, etc
While doing all this, things like build infrastructure and l10n would be
largely, if not completely, unaffected. Lots of details TBD there, but
the point is we'd have a lot of flexibility in how we approach this
while the amount of effort required before our git mirror is functional
will be minimal compared to doing a wholesale switch as described below.
We would of course need to run high availability servers for both hg and
git, and eventually the atomic bidirectional bridge (all of which would
likely be on the same hardware).
Option 2 is where this discussion started (in the Tuesday meeting a few
weeks ago,
https://wiki.mozilla.org/Platform/2013-05-07#Should_we_switch_from_hg_to_git.3F).
Since then I've had a number of conversations and have been convinced
that a wholesale change is the less attractive option. The cost of a
wholesale change will be *huge* on the infrastructure end, to a point
where we need to question whether the benefits are worth the cost. I
have also spoken with other large engineering orgs about git performance
limitations, one of which is doing the opposite switch, going from git
to hg. While I don't see us hitting those limitations any time soon, I
also don't think the risk of hitting those limitations is one we want to
take in a wholesale change at this point.
One inevitable question that will arise here if we were to switch
wholesale over to git is whether we're also considering hosting
Firefox/Gecko development on Github, and the answer to that question at
this point is no (but we will likely continue to mirror mozilla-central
etc to Github). We've been in talks with Github, but we will not get the
reliability guarantees we need nor the flexibility we need if we were to
host Gecko development on Github. I.e. Github issues are not flexible
enough, pull request related data would live outside of our control,
etc. Please refer to https://wiki.mozilla.org/SCM/GitHubFAQ for more on
this topic, or start new threads about this if further discussion is needed.
I'd love to hear feedback here on whether you think we should go ahead
and make git and hg work side by side, switch wholesale to git, or
change nothing. I'd also love input on what pieces of infrastructure we
have (both inside and outside of engineering) that are dependent on
mercurial today. Identifying those systems up front would be very
helpful. Lawrence Mandel has already create a wiki at
https://wiki.mozilla.org/Scm/GitMigrationPlan#Tasks to track that work,
please help us populate that list as much as you can!
--
jst
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
