Re: The future of commit access policy for core Firefox

Responding to an old thread... (had saved as draft but didn't realize I hadn't sent). Only replying to .platform here since last time I cross-post-replied it didn't show up. >I want to explicitly state that we're moving towards >N=~10 people having raw push access to the Firefox repos with the

Re: The future of commit access policy for core Firefox

On Thu, Mar 9, 2017 at 1:53 PM, Mike Connor wrote: > (please direct followups to dev-planning, cross-posting to governance, > firefox-dev, dev-platform) > > > Nearly 19 years after the creation of the Mozilla Project, commit access > remains essentially the same as it has

Re: The future of commit access policy for core Firefox

On Fri, Mar 17, 2017 at 3:55 AM, Bobby Holley wrote: > On Fri, Mar 17, 2017 at 12:41 AM, Jean-Yves Avenard > > wrote: > > > And yet, despite many people’s concerns, it appears that policy of > > removing r+ whenever a new push has been made

Re: The future of commit access policy for core Firefox

On Fri, Mar 17, 2017 at 12:41 AM, Jean-Yves Avenard wrote: > And yet, despite many people’s concerns, it appears that policy of > removing r+ whenever a new push has been made effective. > To my knowledge, mconnor's proposal has yet to get anywhere close to an actual

Re: The future of commit access policy for core Firefox

And yet, despite many people’s concerns, it appears that policy of removing r+ whenever a new push has been made effective. And so, here I am with a r+ requesting to fix a comment, I have to ask for r+ again from someone not in my timezone and already on week-end. Turn around time, from 30

Re: The future of commit access policy for core Firefox

On 2017-03-14 7:10 PM, Jean-Yves Avenard wrote: /me just loves when a new set of “rules” are put in place to prevent a problem that has never existed so far and will be a hindrance to everyone in the future. Two dozen or so of our most veteran engineers are deeply involved in this

Re: The future of commit access policy for core Firefox

> On 12 Mar 2017, at 9:40 pm, Ehsan Akhgari wrote: > And I still don't understand what the proposal means with rebases in > practice. What if, after automation tries to land your change after you > got your final r+ the final rebase fails and you need to do a manual >

Re: The future of commit access policy for core Firefox

On Monday, March 13, 2017 at 7:45:44 AM UTC-7, Byron Jones wrote: > David Burns wrote: > > We should try mitigate the security problem and fix our nit problem > > instead of bashing that we can't handle re-reviews because of nits. > one way tooling could help here is to allow the reviewer to make

Re: The future of commit access policy for core Firefox

On 2017-03-12 4:53 PM, smaug wrote: > On 03/12/2017 10:40 PM, Ehsan Akhgari wrote: >> On 2017-03-11 9:23 AM, smaug via governance wrote: >>> On 03/11/2017 08:23 AM, Nicholas Nethercote wrote: On Sat, Mar 11, 2017 at 2:23 PM, smaug via governance < governa...@lists.mozilla.org> wrote:

Re: The future of commit access policy for core Firefox

On 13/03/17 14:45, Byron Jones wrote: David Burns wrote: We should try mitigate the security problem and fix our nit problem instead of bashing that we can't handle re-reviews because of nits. one way tooling could help here is to allow the reviewer to make minor changes to the patch before it

Re: The future of commit access policy for core Firefox

David Burns wrote: We should try mitigate the security problem and fix our nit problem instead of bashing that we can't handle re-reviews because of nits. one way tooling could help here is to allow the reviewer to make minor changes to the patch before it lands. ie. "r+, fix typo in comment

Re: The future of commit access policy for core Firefox

As the manager of the sheriffs, I am in favour of this proposal. The reasons why are as follow (and to note there are only 3 paid sheriffs to try cover the world): * A number of r+ with nits land up in the sheriffs queue for checkin-needed. This then puts the onus on the sheriffs, not the

Re: The future of commit access policy for core Firefox

On 03/10/2017 12:59 AM, Bobby Holley wrote: At a high level, I think the goals here are good. However, the tooling here needs to be top-notch for this to work, and the standard approach of flipping on an MVP and dealing with the rest in followup bugs isn't going to be acceptable for something

Re: The future of commit access policy for core Firefox

On Mon, Mar 13, 2017 at 12:22 AM, Frederik Braun wrote: > On 12.03.2017 04:08, Cameron Kaiser wrote: > > On 3/10/17 4:38 AM, Masatoshi Kimura wrote: > >> On 2017/03/10 6:53, Mike Connor wrote: > >>> - Two-factor auth must be a requirement for all users approving or > >>>

Re: The future of commit access policy for core Firefox

On 12.03.2017 04:08, Cameron Kaiser wrote: > On 3/10/17 4:38 AM, Masatoshi Kimura wrote: >> On 2017/03/10 6:53, Mike Connor wrote: >>> - Two-factor auth must be a requirement for all users approving or >>> pushing a change. >> >> I have no mobile devices. How can I use 2FA? >> >>

Re: The future of commit access policy for core Firefox

On 03/12/2017 10:40 PM, Ehsan Akhgari wrote: On 2017-03-11 9:23 AM, smaug via governance wrote: On 03/11/2017 08:23 AM, Nicholas Nethercote wrote: On Sat, Mar 11, 2017 at 2:23 PM, smaug via governance < governa...@lists.mozilla.org> wrote: I'd be ok to do a quick r+ if interdiff was working

Re: The future of commit access policy for core Firefox

On 2017-03-11 9:23 AM, smaug via governance wrote: > On 03/11/2017 08:23 AM, Nicholas Nethercote wrote: >> On Sat, Mar 11, 2017 at 2:23 PM, smaug via governance < >> governa...@lists.mozilla.org> wrote: >>> >>> I'd be ok to do a quick r+ if interdiff was working well. >> >> Depending on the

Re: The future of commit access policy for core Firefox

On Fri, Mar 10, 2017 at 9:03 PM, L. David Baron wrote: > On Friday 2017-03-10 19:33 -0800, Eric Rescorla wrote: > > We have been using Phabricator for our reviews in NSS and its interdiffs > > work pretty well > > (modulo rebases, which are not so great), and it's very easy to

Re: The future of commit access policy for core Firefox

On 3/10/17 4:38 AM, Masatoshi Kimura wrote: On 2017/03/10 6:53, Mike Connor wrote: - Two-factor auth must be a requirement for all users approving or pushing a change. I have no mobile devices. How can I use 2FA? Previously I was suggested to buy a new PC and SSD only to shorten the

Re: The future of commit access policy for core Firefox

On Sunday, March 12, 2017 at 1:23:45 AM UTC+11, smaug wrote: > On 03/11/2017 08:23 AM, Nicholas Nethercote wrote: > > On Sat, Mar 11, 2017 at 2:23 PM, smaug via governance < > > gov...@lists.mozilla.org> wrote: > >> > >> I'd be ok to do a quick r+ if interdiff was working well. > > > > Depending

Re: The future of commit access policy for core Firefox

On 03/11/2017 08:23 AM, Nicholas Nethercote wrote: On Sat, Mar 11, 2017 at 2:23 PM, smaug via governance < governa...@lists.mozilla.org> wrote: I'd be ok to do a quick r+ if interdiff was working well. Depending on the relative timezones of the reviewer and reviewee, that could delay landing

Re: The future of commit access policy for core Firefox

On Sat, Mar 11, 2017 at 7:23 AM, Nicholas Nethercote wrote: > > Depending on the relative timezones of the reviewer and reviewee, that > could delay landing by 24 hours or even a whole weekend. > > As someone working from Europe and 90% of the time with people from the

Re: The future of commit access policy for core Firefox

On Sat, Mar 11, 2017 at 2:23 PM, smaug via governance < governa...@lists.mozilla.org> wrote: > > I'd be ok to do a quick r+ if interdiff was working well. Depending on the relative timezones of the reviewer and reviewee, that could delay landing by 24 hours or even a whole weekend. In general

Re: The future of commit access policy for core Firefox

On Friday 2017-03-10 19:33 -0800, Eric Rescorla wrote: > We have been using Phabricator for our reviews in NSS and its interdiffs > work pretty well > (modulo rebases, which are not so great), and it's very easy to handle LGTM > with > nits and verify the nits. For what it's worth, I think proper

Re: The future of commit access policy for core Firefox

On Fri, Mar 10, 2017 at 7:23 PM, smaug via governance < governa...@lists.mozilla.org> wrote: > On 03/10/2017 12:59 AM, Bobby Holley wrote: > >> At a high level, I think the goals here are good. >> >> However, the tooling here needs to be top-notch for this to work, and the >> standard approach of

Re: The future of commit access policy for core Firefox

Ehsan Akhgari wrote: Even with a single reviewer, I often times end up making some trivial changes to my patches to fix stupid mistakes and issues that I know the reviewer doesn't care enough to want to look at before landing. In general our code review process has a lot of flexibility built

Re: The future of commit access policy for core Firefox

Me too. Have a phone which does what I need (calling people and be called:) ) No need for a mobile device which has its own security and usability problems. FRG Masatoshi Kimura wrote: On 2017/03/10 6:53, Mike Connor wrote: - Two-factor auth must be a requirement for all users approving

Re: The future of commit access policy for core Firefox

On Friday, March 10, 2017 at 7:38:57 AM UTC-5, Masatoshi Kimura wrote: > On 2017/03/10 6:53, Mike Connor wrote: > >- Two-factor auth must be a requirement for all users approving or > >pushing a change. > > I have no mobile devices. How can I use 2FA? > > Previously I was suggested to

Re: The future of commit access policy for core Firefox

On 2017/03/10 14:00, Mike Hommey wrote: > While we're talking about drag on productivity, there's already one that > comes from autoland already, which is that you can't easily land fixups > for stupid mistakes (like, a build failure on one platform, or other > lame things that happen when things

Re: The future of commit access policy for core Firefox

On 2017/03/10 6:53, Mike Connor wrote: >- Two-factor auth must be a requirement for all users approving or >pushing a change. I have no mobile devices. How can I use 2FA? Previously I was suggested to buy a new PC and SSD only to shorten the build time. Now do I have to buy a smartphone

Re: The future of commit access policy for core Firefox

On Thu, Mar 09, 2017 at 08:25:17PM -0800, zbranie...@mozilla.com wrote: > As others stated, the idea that patch cannot be altered after r+ has a > massive effect on productivity. I can't overstate how much it would impact > day-to-day work for engineers, and I don't really see an easy way out. >

Re: The future of commit access policy for core Firefox

As others stated, the idea that patch cannot be altered after r+ has a massive effect on productivity. I can't overstate how much it would impact day-to-day work for engineers, and I don't really see an easy way out. Even if we added "approval to land with minor changes" there's a) no way to

Re: The future of commit access policy for core Firefox

Mike Connor wrote: > (please direct followups to dev-planning, cross-posting to governance, > firefox-dev, dev-platform) > > > Nearly 19 years after the creation of the Mozilla Project, commit access > remains essentially the same as it has always been. We've evolved the > vouching process a

Re: The future of commit access policy for core Firefox

On Thursday, March 9, 2017 at 1:53:50 PM UTC-8, Mike Connor wrote: > >- Direct commit access to repositories will be strictly limited to >sheriffs and a subset of release engineering. > - Any direct commits by these individuals will be limited to fixing > bustage that

Re: The future of commit access policy for core Firefox

On 2017-03-09 6:51 PM, Justin Dolske wrote: > Similar to "r+ with fixes" are cases where a patch (or patch series) > requires reviews from a multitude of people. Which means variable delays in > getting reviews, during which things may slightly bitrot or be trivially > modified based on feedback

Re: The future of commit access policy for core Firefox

On Thu, Mar 09, 2017 at 03:51:07PM -0800, Justin Dolske wrote: > I suppose this policy also implies no more "Typo fix, no bug" landings. But > I never really liked those anyway, so I'm fine with that. Bugs are cheap! :) Considering the overhead of creating a bug, attaching a patch, requesting a

Re: The future of commit access policy for core Firefox

Similar to "r+ with fixes" are cases where a patch (or patch series) requires reviews from a multitude of people. Which means variable delays in getting reviews, during which things may slightly bitrot or be trivially modified based on feedback from other reviewers. Code refactorings are one

Re: The future of commit access policy for core Firefox

On Thu, Mar 9, 2017 at 3:11 PM, wrote: > On Friday, March 10, 2017 at 10:53:50 AM UTC+13, Mike Connor wrote: > > (please direct followups to dev-planning, cross-posting to governance, > > firefox-dev, dev-platform) > > > > > > Nearly 19 years after the creation of

Re: The future of commit access policy for core Firefox

On Friday, March 10, 2017 at 10:53:50 AM UTC+13, Mike Connor wrote: > (please direct followups to dev-planning, cross-posting to governance, > firefox-dev, dev-platform) > > > Nearly 19 years after the creation of the Mozilla Project, commit access > remains essentially the same as it has always

Re: The future of commit access policy for core Firefox

First, let me state that I am generally in support of this type of change. More comments below. On Thu, Mar 9, 2017 at 1:53 PM, Mike Connor wrote: > (please direct followups to dev-planning, cross-posting to governance, > firefox-dev, dev-platform) > > > Nearly 19 years

Re: The future of commit access policy for core Firefox

At a high level, I think the goals here are good. However, the tooling here needs to be top-notch for this to work, and the standard approach of flipping on an MVP and dealing with the rest in followup bugs isn't going to be acceptable for something so critical to our productivity as landing

The future of commit access policy for core Firefox

(please direct followups to dev-planning, cross-posting to governance, firefox-dev, dev-platform) Nearly 19 years after the creation of the Mozilla Project, commit access remains essentially the same as it has always been. We've evolved the vouching process a number of times, CVS has long since