…DVCS Survey Summary

[Refer to the main page for additional context.]


A long time ago (December of 2011), I sent out a brief survey on DVCS usage to Mozilla folks (and asked them to spread wider). While there were only 42 responses, there were some interesting patterns.


I am neither a statistician nor a psychometrician.

I believe you can see the raw summary at via this link. What follows are the informal inferences I drew from the results (remember the disclaimer).

Commit to git is not the issue:

  • Several level 3 committers volunteered [1] the information that commit to git would be of little benefit to their productivity, due to tooling they have.
  • There are several developer written toolkits being used to ease working with hg.m.o. They include transparent push-to-try from git.

Git is not the issue:

  • The number of "passionate for git" is about equal to "passionate for hg" (small survey size).
  • One respondent volunteered [1] that he found git very difficult to explain to new community members, others felt the opposite.

The Issue Is…

The issue is some level of official support of social coding sites:

  • 86% mentioned "pull requests" as a better review process than patch submittal.
  • A number of volunteered comments expressed some level of confusion, including which github repo to use, how to start a new project, what workflows to use to interact with hg.m.o, etc.

A Plan

These survey results, plus some technical investigation into what was possible with given tools, led to forming the (very agressive) 2012 Q1 goal captured in bug 713782. A looser summary of that follows.

End the confusion!

  • Provide an officially supported repositories for releng supported prodcuts on github & bitbucket
  • Coordinate tooling to allow git to work with hg.m.o
  • Document "how to set up git to work with releng" [2]

Prepare for disaster

  • ensure every releng supported product has an inside-the-firewall repository of record.


[1] (1, 2) When the survey allowed text input, and responses were specific beyond the question, I count that as a "volunteered" answer of greater "weight" than a checkbox response.
[2] There are several categories of Mozilla source code on github: Product code, SAAS code, and experimental code are the big ones. The scope of these recomendations is only for product code that will be built, tested, and released by the releng machinery.

3 Responses to …DVCS Survey Summary

  1. I think I missed the survey, so here are my two cents: I have Level 3 commit access to Mozilla and push my own changes. I also work on other (unrelated) free software projects that use Git for their master repository, so I have a reasonable amount of experience with both.

    At the data-model level, as far as I can tell, Mercurial and Git are isomorphic with one exception, i.e. Mercurial bakes branch names into commits and Git doesn’t. This doesn’t strike me as a terribly big deal either way. It is an empirical fact that Git is more efficient in terms of both disk space and network speed, but on my computers, the difference is not big enough to bother me.

    I feel very strongly that Mercurial’s CLI is superior to Git’s — so much so that if something as big or complicated as mozilla-central, that I needed to work on, had its master repository in Git, I would find a way to convert it back into Mercurial, even if only locally. It isn’t just a matter of elegance; I don’t trust Git’s CLI to do what I want. Things that any Mozilla committer may need to do, that I would not be able to do in Git without someone walking me through it every. single. time., include:

    * Updating not-yet-submitted changes for conflicting work by others
    * Backing out a patch
    * Applying a patch to any branch other than the currently selected one

    I find it completely baffling how people can say that Git’s branch handling is superior to anything. It makes no sense at all to me, and every time I try to do anything with branches in Git I wind up wasting at least an hour just to get back to where I was before I started. (The really baffling thing is, the data model does make sense! It’s only the tools that render it unusable.)

  2. Hal Wine

    Zack (& likely others) – one point I must not have made clear enough is that this is NOT moving mozilla-central (or any other releng supported repository) to git. The “repository of record” for these releng supported repositories will remain mercurial at this point. Ideally, which DVCS a developer chooses to use should be as personal a choice as which editor to use (and we see overtones of the ancient “vi-vs-emacs” debates in the “hg-vs-git” debates).

    What is being proposed here is also making a read only copy of mozilla-central available on github. This is far easier and quicker than just planning a migration to git, and should meet >80% of the needs expressed in the survey results.

  3. To be clear, what you propose is totally fine with me.