FWIW, for the 300+ accounts that I vouched for, I relied on risk
management. I looked at what I knew about the folks that I vouched for,
and what they're intending to do, and what mitigation strategy there was
when things wouldn't go as intended.
That risk management also shaped how we're shipping localizations of
Firefox today. That we only ship revisions that went through an
independent technical review for branded builds is part of that.
I wouldn't use the word "trust" to describe what I've done for VCS
accounts so far.
Axel
On 04/08/16 19:58, Mike Connor wrote:
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 <[email protected]> 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
[email protected]
https://mail.mozilla.org/listinfo/firefox-dev
_______________________________________________
governance mailing list
[email protected]
https://lists.mozilla.org/listinfo/governance
