On Wed, Aug 3, 2016 at 10:31 PM, Mitchell Baker <mitch...@mozilla.com> wrote:
> Ah yes, good point. For me personally, there's very little that's > contentious about adapting our policies to reflect changing engineering > practices. When I wrote a bunch of our original policies many years back, > they were a reflection of actual practice at the time with our > aspirations. So updating policy to reflect today's practices seems a marof > a well managed project. So probably there's a bunch to do here. > > On the scope side, does "firefox" capture it? If we mean the set of code > that ships as part of Firefox, then it clearly includes Gecko,etc, which we > would want. > I want to say yes. However, even defining "code that ships as part of Firefox" under the same policy could be difficult. We've always had 3rd party code like libbzip2 and more recently libraries like ICU and WebRTC vendored in mozilla-central. These were projects where Mozilla didn't really do much upstream work or at least weren't in the driver's seat: we just periodically dumped upstream changes into mozilla-central. With the Oxidation of Gecko, we're starting to vendor Rust components that are primarily developed by Mozilla but are done so outside the Firefox umbrella. There are even tentative plans to have Servo "mirrored" into Firefox repositories in real time, effectively bringing the Servo project into scope for Firefox's policies (in theory). With Firefox's Go Faster project, we are starting to ship code to users that never lands in an existing Firefox repository on hg.mozilla.org. It doesn't necessarily even go through the same code review workflow or tools. This includes the entirety of the Test Pilot "experiments," for example (see https://github.com/mozilla/testpilot). There are projects like Firefox for iOS that use the "Firefox" brand name but live outside the traditional Firefox code/tools umbrella. If you want to be cynical or paranoid, you could say these things are threats to the best practices and policies that have been established around Firefox [for Android/Desktop + Gecko]. They definitely test the boundaries of what a "Firefox Commit Access Policy" means. I can make the argument that there should be a governance module covering the rules for what gets shipped to Firefox [for Android/Desktop] users (not necessarily limited to the mozilla-central bits) and how that is reviewed, audited, etc. The commit access policy would be under purview of that module. FWIW, I've been put in a few positions over the years as a Firefox build system peer where I was asked to review code that introduced 3rd party source into Firefox. Oftentimes I was the one asking questions about install size bloat, license review, etc. I did this because they are important questions to ask, not because I was following some procedure (no well-defined or followed procedure exists AFAIK). (I've wondered what would have happened if they didn't land on my plate and nobody asked these questions.) I can also point to instances where large Firefox features were developed at Mozilla outside of Firefox's more stringent peer review workflows and then were effectively thrown over a wall and incorporated into Firefox. Firefox Sync was more or less done this way. There are things in the Firefox Sync code that would have never received review from a Firefox module peer. But by the time we wanted to "graduate" the "Weave" extension to a core feature of Firefox, it was either spend months to rewrite things or ship. We chose to ship and we're still living with the technical debt and performance issues as a result. I'm no fan of bureaucracy and excessive policy, but given the security, privacy, stability, performance, and long-term engineering productivity implications of shipping code to hundreds of millions of users and maintaining that code, I think I would feel better if there were more formal governance for incorporating/shipping code into/with Firefox not developed under the traditional Firefox module governance system. This would include decisions/policies on not only 3rd party code like WebRTC and ICU, but also Mozilla-influenced projects like Rust and Servo components and Test Pilot. As it stands, there is no central entity fulfilling that role (I think the closest we have is Release Management and they tend to not get involved until close to ship time). > I agree that acting as if this policy governs code it doesn't is not > helpful. And by being clear what it does cover, it also makes it clear > where we are making a different risk / convenience / reward balance. > > Mitchell > > > > > On 8/3/16 10:06 PM, Gregory Szorc wrote: > > On Wed, Aug 3, 2016 at 8:20 PM, Mitchell Baker <mitch...@mozilla.com> > wrote: > >> ideal followup is governance ... cross posting to reach those likely to >> be interested >> >> I'm currently the owner of the Commit Access Policy module. That's >> because I wrote the original policy and did what was necessary to get it >> implemented. (That's old history!) I was also engaged in the rewrite to >> the current policy but not at the same level. There's a separate module for >> implementation, owned by Marcia Knous. >> >> Someone closer to our code should own this policy going forward. I have >> a few ideas but there are many people who have become active whom I don't >> yet know. So if there's someone you think should own this policy please do >> let me know. It should be someone familiar with how things work, who has a >> sense for good, workable practices that protect are code and a good >> communicator. >> >> current policy is here: https://www.mozilla.org/en-US/ >> about/governance/policies/commit/access-policy/ >> > > 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. > > The reality of today is that the "Mozilla Commit Access Policy" is > effectively the "Firefox Commit Access Policy." There are large Mozilla > projects to which the existing policy does not apply or is simply ignored. > On GitHub, each organization or project has the freedom to define its own > policy. This is both good and bad. Mostly good for the flexibility and > convenience. Bad in that it has historically been the wild west and there > are some gotchas in GitHub's permissions model that can lead to access > being granted where it shouldn't be. See https://wiki.mozilla.org/Github > for more on the policy that more or less governs the "mozilla" organization > on GitHub. Of course there are other Mozilla-affiliated organizations, like > Rust, Servo, Bugzilla, TaskCluster, ... > > 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 do believe that Firefox needs a formal policy. I consider security and > legal requirements as significant drivers of at least the Firefox commit > policy. So having someone with well-formed connections to those groups and > who knows the server maintainers would be ideal. I know Doug Turner has > expressed interest in the Firefox commit policy and his org runs the > Mozilla-hosted version control servers and Firefox automation. Ditto for > Lawrence Mandel and Jonathan Griffin. Hal Wine has done a lot of work on > establishing sanity to GitHub access, has familiarity with Firefox access > and security concerns, has access to the version control servers, and seems > to have connections throughout Mozilla. Those are the first names that jump > out to me. But I think choosing someone really depends on the scope of the > module/policy going forward... > > > _______________________________________________ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance
