Re: Owner for Commit Access Policy

[Gervase Markham]

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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Owner for Commit Access Policy

[Gervase Markham]

On 04/08/16 16:22, Hal Wine wrote:
> On Thu, Aug 4, 2016 at 1:48 AM, Gervase Markham  > wrote:
> 
> 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. 
> 
> Actually, there are some modern attempts at this - times have changed.

I'm not sure any of the things you name amount to an attempt to write a
single policy for all Mozilla repos governing who can check in or not; I
accept that there have been more scope-limited efforts, of course.

> 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.
> 
> Since key upstream repos are now on GitHub (e.g Rust), this really means
> we need a plan that covers GitHub, imo.

A very fair point. (Although it need not cover all of our Github.)

> As is often the case, these "nice to haves" are "underfunded mandates"
> until something happens. There are a few of us who keep trying to push
> the rock up the hill in between the events that get everyone's attention.

:-) It's one of those "buying insurance" things - if we don't do this,
perhaps nothing bad will happen, but perhaps something will, and it'll
be much worse for not having done it.

Gerv

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed change to Commit Access Policy Level 3

[David Burns]

Looks great to me!

David

On 4 August 2016 at 06:20, Mitchell Baker  wrote:

> Over time we've made a series of exceptions to the level 3 requirements
> for Sheriffs and this proposal addresses that.
>
>
> The current Policy for level 3 is:
>
> Level 3 - Core Product Access
>
> Requirements: two vouchers - module owners or peers of code stored
> at this level
>
>
> The issue is that Sheriffs typically need level 3 access to fulfill their
> roles.  But they aren't chosen based on number and quality of patches, so
> often don't meet the current requirements.  Today we go through an
> exception process.  The thinking is that this process is unneeded for a set
> of people to whom we've delegated Sheriff authority.
>
>
> The proposal is to change the text as follows:
>
> from:"module owners or peers of code stored at this level"
> to:  "module owners or peers of code stored at this level or owners or
> peers of the 'Tree Sheriffs' module."
>
>
>
> Mitchell
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed change to Commit Access Policy Level 3

[Johnny Stenback]

SGTM!

- jst


On Thu, Aug 4, 2016 at 8:57 AM, David Burns  wrote:
> Looks great to me!
>
> David
>
> On 4 August 2016 at 06:20, Mitchell Baker  wrote:
>
>> Over time we've made a series of exceptions to the level 3 requirements
>> for Sheriffs and this proposal addresses that.
>>
>>
>> The current Policy for level 3 is:
>>
>> Level 3 - Core Product Access
>>
>> Requirements: two vouchers - module owners or peers of code stored
>> at this level
>>
>>
>> The issue is that Sheriffs typically need level 3 access to fulfill their
>> roles.  But they aren't chosen based on number and quality of patches, so
>> often don't meet the current requirements.  Today we go through an
>> exception process.  The thinking is that this process is unneeded for a set
>> of people to whom we've delegated Sheriff authority.
>>
>>
>> The proposal is to change the text as follows:
>>
>> from:"module owners or peers of code stored at this level"
>> to:  "module owners or peers of code stored at this level or owners or
>> peers of the 'Tree Sheriffs' module."
>>
>>
>>
>> Mitchell
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Build System Project - Latest Update

[David Burns]

Below is a highlight of all work the build peers have done since the last
report[1].

The build peers have been working to get faster builds in automation as
well as well as local developers. We have updated the way that Taskcluster
decision and linting jobs use version control[2]. This has driven down the
times for those jobs from 3 minutes to ~9 seconds.

We are still working on getting the sccache rewrite out. We are hitting a
few issues on try but this is to be expected. Hopefully this will be out
soon.

We’re also looking into running automation builds in EC2 on instances with
more and faster CPU cores so they complete faster[3].

On the local build side we have moved some of the header checks[4] to the
python configure. These were fairly self contained configure steps and ripe
for porting. They removed ~1300 lines of configure code which is a huge
win! We have also been working through some of the potential problems with
moving to a new build backend. This is going to be a little slow at first
as we try get specific parts using the alternate build backend.

Some initial work on replacing the NSS build system is showing great
promise[5].

We have also been moving Windows specific configure code around. This is
part of our goal to make that step faster in the build. Nathan, our intern,
has also been making great strides in his work to move MozillaBuild to
msys2 allowing easier hackability of the build. He also did his intern
presentation[6]. I highly recommend you watch it!

Nathan will be leaving us at the end of next week (12 August) and the build
peers want to thank him for all his hard work over his internship and wish
him luck in his future endeavours! .

[1]
https://groups.google.com/d/msg/mozilla.dev.platform/4Vyez4stDyg/jlQeQ5TACAAJ

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1247168

[3] https://bugzilla.mozilla.org/show_bug.cgi?id=
1290282

[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1269517

[5] https://bugzilla.mozilla.org/show_bug.cgi?id=1237872#c3

[6]  https://air.mozilla.org/down-the-rabbit-hole/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed change to Commit Access Policy Level 3

[Lawrence Mandel]

+1  Good change.

Lawrence

On Wednesday, 3 August 2016, Mitchell Baker  wrote:

> Over time we've made a series of exceptions to the level 3 requirements
> for Sheriffs and this proposal addresses that.
>
>
> The current Policy for level 3 is:
>
> Level 3 - Core Product Access
>
> Requirements: two vouchers - module owners or peers of code stored
> at this level
>
>
> The issue is that Sheriffs typically need level 3 access to fulfill their
> roles.  But they aren't chosen based on number and quality of patches, so
> often don't meet the current requirements.  Today we go through an
> exception process.  The thinking is that this process is unneeded for a set
> of people to whom we've delegated Sheriff authority.
>
>
> The proposal is to change the text as follows:
>
> from:"module owners or peers of code stored at this level"
> to:  "module owners or peers of code stored at this level or owners or
> peers of the 'Tree Sheriffs' module."
>
>
>
> Mitchell
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform