I think there are at least five reasonably distinct classes of repositories in active use. I'm sure we could be more fine-grained as needed. I would suggest that if someone were to draft a new policy, access to each class of repo should have a separate sign-off process.
* Firefox and upstream components (across Hg and Github) * Product localization repositories (mostly strings) * Key web infrastructure and tooling (i.e. Mozilla services, www.mozilla.org, etc) * Tools and libraries that we and others build and use. * Experiments and side projects (add-ons, proof of concept services, even try server, etc) Ultimately, this is about trust, not technical competency. In practice we don't vouch for commit access based on technical skills/reviewer ability, we do it because we believe we can trust that individual to a) behave intelligently in dealing with repos and b) maintain necessary security over key access to prevent system compromises. What we're ideally constructing here is a policy to scope and manage trust domains for accessing Mozilla repositories. In that light, I think the path to victory is: * Identify the right groupings of repositories (as above, or different) * Identify the right verification process for getting access to each grouping * Implementing necessary technical changes (including potentially splitting or reworking the Mozilla Github org) to ensure sane group-based controls are in place. While I'm in agreement with some of the concerns Greg's just raised around integration from third parties, I think that's outside of the scope of commit access policy, and everything to do with whether the current module ownership structure for our products is effective. That's a separate, complicated discussion worth having. -- Mike On Thu, Aug 4, 2016 at 4:48 AM, Gervase Markham <g...@mozilla.org> wrote: > On 04/08/16 06:06, Gregory Szorc wrote: > > I'm going to say something that might be a bit contentious: I think a > > single commit access policy for all of Mozilla reflects the needs of > > Mozilla from several years ago, not the needs of Mozilla today. The world > > has changed. Mozilla has changed. The policy was written before > distributed > > version control was popular, before services like GitHub. > > I don't think that's contentious; I think it's a totally accurate > assessment :-) > > > The reality of today is that the "Mozilla Commit Access Policy" is > > effectively the "Firefox Commit Access Policy." > > Yep. And we should probably rename it as such. > > > I'm not sure how formal we want to be on a commit policy that attempts to > > govern all of Mozilla and/or that governs less established projects or > > projects outside the Firefox umbrella. > > I had a few abortive goes at this a few years ago; it's an enormous > effort to get everyone on the same bandwagon, and just leads to the > creation of bureaucracy for no value. Let's not try it again. But I > agree with you that having a formal policy for Firefox, and any repos > which are upstream of it, makes sense. Knowing who can check in to a > codebase which gets shipped to hundreds of millions of people is a good > idea. > > Gerv > > _______________________________________________ > firefox-dev mailing list > firefox-...@mozilla.org > https://mail.mozilla.org/listinfo/firefox-dev > _______________________________________________ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance
