Weirdly enough, I'm hoping we're using one or the other, and I think git
is more promising. Yes, I need to rewrite a bunch of stuff l10n-wise,
but still.
I actually think that we should aim high. Don't bother about command
lines, but what takes us to a system where people can just contribute to
Firefox and Gecko on the web.
Find the bug, click a button, start editing in your browser, try,
review, merge.
If we can get that working without involving a single thing but a
browser, than we're making a change. git command line vs hg command line
doesn't bring that change.
The best model people have come up so far is a fork per bug (LegNeato at
the time) or per user (github).
I see how someone can serve a few 100k of forks (see our bugcount) on
git storage, but I don't see that with hg.
That to me is the compelling argument.
Doing both hg and git sounds like we'll get the worst of both worlds.
I'm also advocating for taking hosting dead serious. We're at least
struggling with the amount of repos we're serving on hg right now,
adding more complexity won't make the systems more stable. Also, Vicent
(githubber) has a great talk about the mistakes they did based on git,
http://vimeo.com/64716825 (30 mins). They're well past the approaches
we're currently at on the hg side.
If we don't have to be compatible with hg, we can also rethink the
constraints that's putting on us for merge days, etc.
I know that option 2 isn't a quick path, and I love the beauty of hg,
but we've failed to use that beauty to make the next game changing
infrastructure to support contributors, IMHO. I can see us having a
better chance with git in the backend.
Quick notes on hackability:
In terms of stable and reliable hacking, hg and git are on par. Shell
out to the command line tools, parse the output.
hg being mostly in python is nice for python hacking, but the code paths
you're hooking in to are far from stable. I do that extensively, and
quite a few ports have been painful. Scripting hg outside of python,
well, yes.
git has libgit2 now, which is a very basic C impl, and jgit, a java
implementation of git. Bindings for libgit2 exist in many languages, but
only the ruby and C# are really good. In particular the python binding
is far from being pythonic, and from being complete. If it's the right
base to create a pythonic api is TBD. Regarding bugzilla integration,
there are perl bindings that get modifications. I refuse to know perl
good enough to make any statement on the value of the perl bindings, though.
Axel
On 5/31/13 2:56 AM, Johnny Stenback wrote:
[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!
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
