Policy for Source Code Commit Access

2 comments for “Policy for Source Code Commit Access”

1. 1

   Ian McKellar said on May 23rd, 2009 at 6:17 pm:

   To cut to my punchline: this sounds like a decent solution to the problem that it’s too hard for good contributors to get access, but I wish we hadn’t ended up here.

   I think the “same-employer” restriction is far more useful in preventing accusations of bias or impropriety than in preventing actual bias or impropriety. Everyone in the Mozilla community shares the goals of having high quality code by high quality contributors, regardless of their employment. In the GNOME community we ended up placing quotas on the maximum number of employees that could sit on the Foundation board for the same reason.

   However, there seems to be a real problem that the vast majority of heavy contributors to the Mozilla tree work at one company. My sense is that there are a couple of factors here. Firstly, it feels like Mozilla source control is moving to be focussed on Firefox. Some projects like Rhino which have active non-MoCo development are no longer maintained in the same tree. Secondly (and somewhat related) there’s little incentive to bring non-Firefox, but Mozilla-based components into Mozilla’s source control. For example Songbird’s multimedia functionality, or Flickr or Flock’s image manipulation code could easily live as part of the Mozilla tree, but don’t. As a result there won’t end up being a ton of module owners whose primary project isn’t Firefox, and since MoCo is (wisely) supporting Firefox contributors there won’t be a many module owners who aren’t employees.

   So I think it makes sense to accept this reality and get rid of the same-employer restriction.

   As an aside, I was a little concerned by the dismissal of code quality as an issue. I spent too many years working on a circa 1999 Mozilla tree to ever give up the code quality fight. I’m concerned that this isn’t ever something that’s “fixed”, its an important part of an engineering culture, and it’s an important part of a successful engineering business. The trade off between code quality (readability, documentation, correctness and completeness) and the rest (features, performance, time to market) is a tough one, but for a project to have longevity we need to strike the right balance. For example, extension developers tell me that the XUL:panel code is atrocious and can very easily crash a user’s browser, but it was pushed in for some of the Places UI.

2. 2

   Mitchell Baker said on June 4th, 2009 at 2:52 pm:

   Ian

   I think there’s a sense that the code review requirements are themselves more effective at producing quality code than they were in the Netscape days when we had the legacy of Netscape access to deal with. Also, I think the idea that commit access is more about trust than code quality was proposed, but didn’t generate a lot of support. I did not make any changes to the Policy regarding quality or scope of things the reviewers should look at.

   On the more module owners, we share an interest in having more new things happening that have space and excitement for new module owners.

   Probably a topic of discussion how much mozilla-based technology should live in the Mozilla tree.