The future of commit access policy for core Firefox

classic Classic list List threaded Threaded
77 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

The future of commit access policy for core Firefox

Mike Connor-4
(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 been replaced by
Mercurial & others, and we've taken some positive steps in terms of
securing the commit process.  And yet we've never touched the core idea of
granting developers direct commit access to our most important
repositories.  After a large number of discussions since taking ownership
over commit policy, I believe it is time for Mozilla to change that
practice.

Before I get into the meat of the current proposal, I would like to outline
a set of key goals for any change we make.  These goals have been informed
by a set of stakeholders from across the project including the engineering,
security, release and QA teams.  It's inevitable that any significant
change will disrupt longstanding workflows.  As a result, it is critical
that we are all aligned on the goals of the change.


I've identified the following goals as critical for a responsible commit
access policy:


   - Compromising a single individual's credentials must not be sufficient
   to land malicious code into our products.
   - Two-factor auth must be a requirement for all users approving or
   pushing a change.
   - The change that gets pushed must be the same change that was approved.
   - Broken commits must be rejected automatically as a part of the commit
   process.


In order to achieve these goals, I propose that we commit to making the
following changes to all Firefox product repositories:


   - 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 automation misses and handling branch merges.
   - All other changes will go through an autoland-based workflow.
      - Developers commit to a staging repository, with scripting that
      connects the changeset to a Bugzilla attachment, and integrates
with review
      flags.
      - Reviewers and any other approvers interact with the changeset as
      today (including ReviewBoard if preferred), with Bugzilla flags as the
      canonical source of truth.
      - Upon approval, the changeset will be pushed into autoland.
      - If the push is successful, the change is merged to mozilla-central,
      and the bug updated.

I know this is a major change in practice from how we currently operate,
and my ask is that we work together to understand the impact and concerns.
If you find yourself disagreeing with the goals, let's have that discussion
instead of arguing about the solution.  If you agree with the goals, but
not the solution, I'd love to hear alternative ideas for how we can achieve
the outcomes outlined above.

-- Mike
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: The future of commit access policy for core Firefox

L. David Baron
On Thursday 2017-03-09 16:53 -0500, Mike Connor wrote:
> I've identified the following goals as critical for a responsible commit
> access policy:
...
>    - The change that gets pushed must be the same change that was approved.

I'm curious what this goal means.  In particular, does it mean that
you're trying to end "review+ if you make the following changes",
and require that reviewers re-review the revisions no matter what?

(If it does mean that, then that's a substantial increase on
reviewer load; if it doesn't, then I'm curious what definition of
"the same" you're using.)

> In order to achieve these goals, I propose that we commit to making the
> following changes to all Firefox product repositories:
>
>
>    - 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 automation misses and handling branch merges.
>    - All other changes will go through an autoland-based workflow.
>       - Developers commit to a staging repository, with scripting that
>       connects the changeset to a Bugzilla attachment, and integrates
> with review
>       flags.
>       - Reviewers and any other approvers interact with the changeset as
>       today (including ReviewBoard if preferred), with Bugzilla flags as the
>       canonical source of truth.
>       - Upon approval, the changeset will be pushed into autoland.
>       - If the push is successful, the change is merged to mozilla-central,
>       and the bug updated.
I'm curious if this will mean that ReviewBoard will be required, or
if it will still be a way to use attachment-based workflows.  (I ask
this because I still consider the ReviewBoard UI unacceptable for
changes that are likely to require re-review.  See
https://bugzilla.mozilla.org/show_bug.cgi?id=1285874#c20 for my form
response on the topic, although I've been a little less picky about
requiring attachments in all cases lately, when I think things
aren't likely to require multiple rounds of review.)

-David

--
饾劄   L. David Baron                         http://dbaron.org/   饾剛
饾劉   Mozilla                          https://www.mozilla.org/   饾剛
             Before I built a wall I'd ask to know
             What I was walling in or walling out,
             And to whom I was like to give offense.
               - Robert Frost, Mending Wall (1914)

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The future of commit access policy for core Firefox

Lawrence Mandel-2
On Thu, Mar 9, 2017 at 5:14 PM, L. David Baron <[hidden email]> wrote:

> On Thursday 2017-03-09 16:53 -0500, Mike Connor wrote:
> > I've identified the following goals as critical for a responsible commit
> > access policy:
> ...
> >    - The change that gets pushed must be the same change that was
> approved.
>
> I'm curious what this goal means.  In particular, does it mean that
> you're trying to end "review+ if you make the following changes",
> and require that reviewers re-review the revisions no matter what?
>
> (If it does mean that, then that's a substantial increase on
> reviewer load; if it doesn't, then I'm curious what definition of
> "the same" you're using.)
>
> > In order to achieve these goals, I propose that we commit to making the
> > following changes to all Firefox product repositories:
> >
> >
> >    - 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 automation misses and handling branch merges.
> >    - All other changes will go through an autoland-based workflow.
> >       - Developers commit to a staging repository, with scripting that
> >       connects the changeset to a Bugzilla attachment, and integrates
> > with review
> >       flags.
> >       - Reviewers and any other approvers interact with the changeset as
> >       today (including ReviewBoard if preferred), with Bugzilla flags as
> the
> >       canonical source of truth.
> >       - Upon approval, the changeset will be pushed into autoland.
> >       - If the push is successful, the change is merged to
> mozilla-central,
> >       and the bug updated.
>
> I'm curious if this will mean that ReviewBoard will be required, or
> if it will still be a way to use attachment-based workflows.  (I ask
> this because I still consider the ReviewBoard UI unacceptable for
> changes that are likely to require re-review.  See
> https://bugzilla.mozilla.org/show_bug.cgi?id=1285874#c20 for my form
> response on the topic, although I've been a little less picky about
> requiring attachments in all cases lately, when I think things
> aren't likely to require multiple rounds of review.)
>

Mark Cote's team is currently working on enabling autoland from Bugzilla so
MozReview will not be required.

Lawrence
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: The future of commit access policy for core Firefox

Andrew  McCreight
In reply to this post by L. David Baron
On Thu, Mar 9, 2017 at 2:14 PM, L. David Baron <[hidden email]> wrote:

> On Thursday 2017-03-09 16:53 -0500, Mike Connor wrote:
> > I've identified the following goals as critical for a responsible commit
> > access policy:
> ...
> >    - The change that gets pushed must be the same change that was
> approved.
>
> I'm curious what this goal means.  In particular, does it mean that
> you're trying to end "review+ if you make the following changes",
> and require that reviewers re-review the revisions no matter what?
>

That's what it sounds like to me. Also, a strict reading of this would
imply that rebasing will require re-review.


>
> (If it does mean that, then that's a substantial increase on
> reviewer load; if it doesn't, then I'm curious what definition of
> "the same" you're using.)
>

In practice, I doubt anybody will look at these re-reviews, so I'm not sure
how much it will help our security.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: The future of commit access policy for core Firefox

Mark C么t茅
In reply to this post by L. David Baron
On 2017-03-09 5:19 PM, Lawrence Mandel wrote:

> On Thu, Mar 9, 2017 at 5:14 PM, L. David Baron <[hidden email]> wrote:
>
>> On Thursday 2017-03-09 16:53 -0500, Mike Connor wrote:
>>> I've identified the following goals as critical for a responsible commit
>>> access policy:
>> ...
>>>    - The change that gets pushed must be the same change that was
>> approved.
>>
>> I'm curious what this goal means.  In particular, does it mean that
>> you're trying to end "review+ if you make the following changes",
>> and require that reviewers re-review the revisions no matter what?
>>
>> (If it does mean that, then that's a substantial increase on
>> reviewer load; if it doesn't, then I'm curious what definition of
>> "the same" you're using.)
>>
>>> In order to achieve these goals, I propose that we commit to making the
>>> following changes to all Firefox product repositories:
>>>
>>>
>>>    - 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 automation misses and handling branch merges.
>>>    - All other changes will go through an autoland-based workflow.
>>>       - Developers commit to a staging repository, with scripting that
>>>       connects the changeset to a Bugzilla attachment, and integrates
>>> with review
>>>       flags.
>>>       - Reviewers and any other approvers interact with the changeset as
>>>       today (including ReviewBoard if preferred), with Bugzilla flags as
>> the
>>>       canonical source of truth.
>>>       - Upon approval, the changeset will be pushed into autoland.
>>>       - If the push is successful, the change is merged to
>> mozilla-central,
>>>       and the bug updated.
>>
>> I'm curious if this will mean that ReviewBoard will be required, or
>> if it will still be a way to use attachment-based workflows.  (I ask
>> this because I still consider the ReviewBoard UI unacceptable for
>> changes that are likely to require re-review.  See
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1285874#c20 for my form
>> response on the topic, although I've been a little less picky about
>> requiring attachments in all cases lately, when I think things
>> aren't likely to require multiple rounds of review.)
>>
>
> Mark Cote's team is currently working on enabling autoland from Bugzilla so
> MozReview will not be required.

Also fwiw we have (finally) made some progress on the bugs you mentioned
there.

Mark


_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: The future of commit access policy for core Firefox

Bobby Holley-2
In reply to this post by Mike Connor-4
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 code. The only reason more developers aren't
complaining about the MozReview+autoland workflow right now is that it's
optional.

The busiest and most-productive developers (ehsan, bz, dbaron, etc) tend
not to pay attention to new workflows because they have too much else on
their plate. The onus needs to be on the team deploying this to have the
highest-volume committers using the new system happily and voluntarily
before it becomes mandatory. That probably means that the team should not
have any deadline-oriented incentives to ship it before it's ready.

Also, getting rid of "r+ with comments" is a non-starter.

bholley


On Thu, Mar 9, 2017 at 1:53 PM, Mike Connor <[hidden email]> 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 number of times, CVS has long since been replaced by
> Mercurial & others, and we've taken some positive steps in terms of
> securing the commit process.  And yet we've never touched the core idea of
> granting developers direct commit access to our most important
> repositories.  After a large number of discussions since taking ownership
> over commit policy, I believe it is time for Mozilla to change that
> practice.
>
> Before I get into the meat of the current proposal, I would like to outline
> a set of key goals for any change we make.  These goals have been informed
> by a set of stakeholders from across the project including the engineering,
> security, release and QA teams.  It's inevitable that any significant
> change will disrupt longstanding workflows.  As a result, it is critical
> that we are all aligned on the goals of the change.
>
>
> I've identified the following goals as critical for a responsible commit
> access policy:
>
>
>    - Compromising a single individual's credentials must not be sufficient
>    to land malicious code into our products.
>    - Two-factor auth must be a requirement for all users approving or
>    pushing a change.
>    - The change that gets pushed must be the same change that was approved.
>    - Broken commits must be rejected automatically as a part of the commit
>    process.
>
>
> In order to achieve these goals, I propose that we commit to making the
> following changes to all Firefox product repositories:
>
>
>    - 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 automation misses and handling branch merges.
>    - All other changes will go through an autoland-based workflow.
>       - Developers commit to a staging repository, with scripting that
>       connects the changeset to a Bugzilla attachment, and integrates
> with review
>       flags.
>       - Reviewers and any other approvers interact with the changeset as
>       today (including ReviewBoard if preferred), with Bugzilla flags as
> the
>       canonical source of truth.
>       - Upon approval, the changeset will be pushed into autoland.
>       - If the push is successful, the change is merged to mozilla-central,
>       and the bug updated.
>
> I know this is a major change in practice from how we currently operate,
> and my ask is that we work together to understand the impact and concerns.
> If you find yourself disagreeing with the goals, let's have that discussion
> instead of arguing about the solution.  If you agree with the goals, but
> not the solution, I'd love to hear alternative ideas for how we can achieve
> the outcomes outlined above.
>
> -- Mike
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning
>
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: The future of commit access policy for core Firefox

Eric Rescorla
In reply to this post by Mike Connor-4
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 <[hidden email]> 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 number of times, CVS has long since been replaced by
> Mercurial & others, and we've taken some positive steps in terms of
> securing the commit process.  And yet we've never touched the core idea of
> granting developers direct commit access to our most important
> repositories.  After a large number of discussions since taking ownership
> over commit policy, I believe it is time for Mozilla to change that
> practice.
>
> Before I get into the meat of the current proposal, I would like to
> outline a set of key goals for any change we make.  These goals have been
> informed by a set of stakeholders from across the project including the
> engineering, security, release and QA teams.  It's inevitable that any
> significant change will disrupt longstanding workflows.  As a result, it is
> critical that we are all aligned on the goals of the change.
>
>
> I've identified the following goals as critical for a responsible commit
> access policy:
>
>
>    - Compromising a single individual's credentials must not be
>    sufficient to land malicious code into our products.
>
> I think this is a good long-term goal, but I don't think it's one we need
to achieve now.
At the moment, I would settle for "only a few privileged people can
single-handedly
land malicious code into our products". In support of this, I would note
that what you
propose below is insufficient to achieve your stated objective, because
there will
still be single person admin access to machines.


>    - Two-factor auth must be a requirement for all users approving or
>    pushing a change.
>    - The change that gets pushed must be the same change that was
>    approved.
>    - Broken commits must be rejected automatically as a part of the
>    commit process.
>
>
> In order to achieve these goals, I propose that we commit to making the
> following changes to all Firefox product repositories:
>
>
>    - 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 automation misses and handling branch merges.
>
> I think this is a good eventual goal, but in the short term, I think it's
probably useful
to keep checkin-needed floating around, especially given the somewhat iffy
state
of the toolchain.


>
>    - All other changes will go through an autoland-based workflow.
>       - Developers commit to a staging repository, with scripting that
>       connects the changeset to a Bugzilla attachment, and integrates with review
>       flags.
>       - Reviewers and any other approvers interact with the changeset as
>       today (including ReviewBoard if preferred), with Bugzilla flags as the
>       canonical source of truth.
>       - Upon approval, the changeset will be pushed into autoland.
>
> Implicit in this is some sort of hierarchy of reviewers (tied to what was
previous L3 commit?)
that says who can review a patch. Otherwise, I can just create a dummy
account, r+ my own
patch, and Land Ho! IIRC Chromium does this by saying that LGTM implies
autolanding
only if the reviewer could have landed the code themselves.

-Ekr



>    - If the push is successful, the change is merged to mozilla-central,
>       and the bug updated.
>
> I know this is a major change in practice from how we currently operate,
> and my ask is that we work together to understand the impact and concerns.
> If you find yourself disagreeing with the goals, let's have that discussion
> instead of arguing about the solution.  If you agree with the goals, but
> not the solution, I'd love to hear alternative ideas for how we can achieve
> the outcomes outlined above.
>
> -- Mike
>
> _______________________________________________
> firefox-dev mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/firefox-dev
>
>
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: The future of commit access policy for core Firefox

Ehsan Akhgari
In reply to this post by Andrew McCreight
On Thu, Mar 9, 2017 at 5:31 PM, Andrew McCreight <[hidden email]>
wrote:

> On Thu, Mar 9, 2017 at 2:14 PM, L. David Baron <[hidden email]> wrote:
>
> > On Thursday 2017-03-09 16:53 -0500, Mike Connor wrote:
> > > I've identified the following goals as critical for a responsible
> commit
> > > access policy:
> > ...
> > >    - The change that gets pushed must be the same change that was
> > approved.
> >
> > I'm curious what this goal means.  In particular, does it mean that
> > you're trying to end "review+ if you make the following changes",
> > and require that reviewers re-review the revisions no matter what?
> >
>
> That's what it sounds like to me. Also, a strict reading of this would
> imply that rebasing will require re-review.
>

On very practical grounds, I found the former unacceptable, and the latter
impractical.  I already can barely keep up with my review load, and other
people who need to do a lot of reviews have similar issues and the
additional review load resulting from this is significant.


>
> >
> > (If it does mean that, then that's a substantial increase on
> > reviewer load; if it doesn't, then I'm curious what definition of
> > "the same" you're using.)
> >
>
> In practice, I doubt anybody will look at these re-reviews, so I'm not sure
> how much it will help our security.
>

I know that I will not in any real detail, even if the process forces me to
check a checkbox somewhere...

--
Ehsan
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: The future of commit access policy for core Firefox

Ehsan Akhgari
In reply to this post by Mike Connor-4
On 2017-03-09 4:53 PM, Mike Connor wrote:
>   * Direct commit access to repositories will be strictly limited to
>     sheriffs and a subset of release engineering.
>       o Any direct commits by these individuals will be limited to
>         fixing bustage that automation misses and handling branch merges.
>   * All other changes will go through an autoland-based workflow.
>       o Developers commit to a staging repository, with scripting that
>         connects the changeset to a Bugzilla attachment, and integrates
>         with review flags.

How is this going to work for the use case of being able to land changes
quickly if, according to the judgement of the patch author, the patch
doesn't need to go through the try server, while being able to monitor
the landing and quickly follow up with a fix in case proven wrong?  Will
there still be a tree like inbound where committers like myself still
have full commit access to where they can use their judgement accordingly?
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: The future of commit access policy for core Firefox

Mark C么t茅
In reply to this post by Mike Connor-4
A mistake we made with MozReview was rolling out a new review tool at
the same time as the new push-based/autoland automation and workflow.
This had a number of repercussions, including requiring users to learn
and use a new review tool in order to benefit from autoland and the
commit-series approach, but also making it difficult to prioritize fixes
and improvements to the various pieces of the system.

Having recognized this, we're decoupling this automation and hooking it
up to BMO, so we can concentrate on getting it right, since most people
are used to using BMO to review patches (this is Project Conduit that
I've blogged and posted about in the mozilla.tools newsgroup).  We've
also grown the team, which was previously understaffed for the size of
the project.  We should have some initial pieces ready to demo in a few
weeks, but we won't officially launch it until it's good and ready.

(Having a richer and more powerful code-review tool is also still a
goal, but we'll deal with that later.)

Mark


On 2017-03-09 5:59 PM, 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 so critical to our
> productivity as landing code. The only reason more developers aren't
> complaining about the MozReview+autoland workflow right now is that it's
> optional.
>
> The busiest and most-productive developers (ehsan, bz, dbaron, etc) tend
> not to pay attention to new workflows because they have too much else on
> their plate. The onus needs to be on the team deploying this to have the
> highest-volume committers using the new system happily and voluntarily
> before it becomes mandatory. That probably means that the team should not
> have any deadline-oriented incentives to ship it before it's ready.
>
> Also, getting rid of "r+ with comments" is a non-starter.
>
> bholley
>
>
> On Thu, Mar 9, 2017 at 1:53 PM, Mike Connor <[hidden email]> 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 number of times, CVS has long since been replaced by
>> Mercurial & others, and we've taken some positive steps in terms of
>> securing the commit process.  And yet we've never touched the core idea of
>> granting developers direct commit access to our most important
>> repositories.  After a large number of discussions since taking ownership
>> over commit policy, I believe it is time for Mozilla to change that
>> practice.
>>
>> Before I get into the meat of the current proposal, I would like to outline
>> a set of key goals for any change we make.  These goals have been informed
>> by a set of stakeholders from across the project including the engineering,
>> security, release and QA teams.  It's inevitable that any significant
>> change will disrupt longstanding workflows.  As a result, it is critical
>> that we are all aligned on the goals of the change.
>>
>>
>> I've identified the following goals as critical for a responsible commit
>> access policy:
>>
>>
>>    - Compromising a single individual's credentials must not be sufficient
>>    to land malicious code into our products.
>>    - Two-factor auth must be a requirement for all users approving or
>>    pushing a change.
>>    - The change that gets pushed must be the same change that was approved.
>>    - Broken commits must be rejected automatically as a part of the commit
>>    process.
>>
>>
>> In order to achieve these goals, I propose that we commit to making the
>> following changes to all Firefox product repositories:
>>
>>
>>    - 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 automation misses and handling branch merges.
>>    - All other changes will go through an autoland-based workflow.
>>       - Developers commit to a staging repository, with scripting that
>>       connects the changeset to a Bugzilla attachment, and integrates
>> with review
>>       flags.
>>       - Reviewers and any other approvers interact with the changeset as
>>       today (including ReviewBoard if preferred), with Bugzilla flags as
>> the
>>       canonical source of truth.
>>       - Upon approval, the changeset will be pushed into autoland.
>>       - If the push is successful, the change is merged to mozilla-central,
>>       and the bug updated.
>>
>> I know this is a major change in practice from how we currently operate,
>> and my ask is that we work together to understand the impact and concerns.
>> If you find yourself disagreeing with the goals, let's have that discussion
>> instead of arguing about the solution.  If you agree with the goals, but
>> not the solution, I'd love to hear alternative ideas for how we can achieve
>> the outcomes outlined above.
>>
>> -- Mike
>> _______________________________________________
>> dev-planning mailing list
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-planning
>>

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: The future of commit access policy for core Firefox

Bobby Holley-2
On Thu, Mar 9, 2017 at 5:08 PM, Mark C么t茅 <[hidden email]> wrote:

> A mistake we made with MozReview was rolling out a new review tool at the
> same time as the new push-based/autoland automation and workflow. This had
> a number of repercussions, including requiring users to learn and use a new
> review tool in order to benefit from autoland and the commit-series
> approach, but also making it difficult to prioritize fixes and improvements
> to the various pieces of the system.
>
> Having recognized this, we're decoupling this automation and hooking it up
> to BMO, so we can concentrate on getting it right, since most people are
> used to using BMO to review patches (this is Project Conduit that I've
> blogged and posted about in the mozilla.tools newsgroup).


This sounds like the right approach.

That said, there can still be hitches in the landing process that are not
necessarily related to the review tool (recall all the edge cases that bz
hit a few weeks ago). Decoupling from the review interface is a good first
step, but building a replacement for {git,hg} push that satisfies
everyone's use-cases is equally hard.

We've also grown the team, which was previously understaffed for the size
> of the project.  We should have some initial pieces ready to demo in a few
> weeks, but we won't officially launch it until it's good and ready.
>

That's great to hear.


>
> (Having a richer and more powerful code-review tool is also still a goal,
> but we'll deal with that later.)
>
> Mark
>
>
> On 2017-03-09 5:59 PM, 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 so critical to
>> our
>> productivity as landing code. The only reason more developers aren't
>> complaining about the MozReview+autoland workflow right now is that it's
>> optional.
>>
>> The busiest and most-productive developers (ehsan, bz, dbaron, etc) tend
>> not to pay attention to new workflows because they have too much else on
>> their plate. The onus needs to be on the team deploying this to have the
>> highest-volume committers using the new system happily and voluntarily
>> before it becomes mandatory. That probably means that the team should not
>> have any deadline-oriented incentives to ship it before it's ready.
>>
>> Also, getting rid of "r+ with comments" is a non-starter.
>>
>> bholley
>>
>>
>> On Thu, Mar 9, 2017 at 1:53 PM, Mike Connor <[hidden email]> 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 number of times, CVS has long since been replaced by
>>> Mercurial & others, and we've taken some positive steps in terms of
>>> securing the commit process.  And yet we've never touched the core idea
>>> of
>>> granting developers direct commit access to our most important
>>> repositories.  After a large number of discussions since taking ownership
>>> over commit policy, I believe it is time for Mozilla to change that
>>> practice.
>>>
>>> Before I get into the meat of the current proposal, I would like to
>>> outline
>>> a set of key goals for any change we make.  These goals have been
>>> informed
>>> by a set of stakeholders from across the project including the
>>> engineering,
>>> security, release and QA teams.  It's inevitable that any significant
>>> change will disrupt longstanding workflows.  As a result, it is critical
>>> that we are all aligned on the goals of the change.
>>>
>>>
>>> I've identified the following goals as critical for a responsible commit
>>> access policy:
>>>
>>>
>>>    - Compromising a single individual's credentials must not be
>>> sufficient
>>>    to land malicious code into our products.
>>>    - Two-factor auth must be a requirement for all users approving or
>>>    pushing a change.
>>>    - The change that gets pushed must be the same change that was
>>> approved.
>>>    - Broken commits must be rejected automatically as a part of the
>>> commit
>>>    process.
>>>
>>>
>>> In order to achieve these goals, I propose that we commit to making the
>>> following changes to all Firefox product repositories:
>>>
>>>
>>>    - 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 automation misses and handling branch merges.
>>>    - All other changes will go through an autoland-based workflow.
>>>       - Developers commit to a staging repository, with scripting that
>>>       connects the changeset to a Bugzilla attachment, and integrates
>>> with review
>>>       flags.
>>>       - Reviewers and any other approvers interact with the changeset as
>>>       today (including ReviewBoard if preferred), with Bugzilla flags as
>>> the
>>>       canonical source of truth.
>>>       - Upon approval, the changeset will be pushed into autoland.
>>>       - If the push is successful, the change is merged to
>>> mozilla-central,
>>>       and the bug updated.
>>>
>>> I know this is a major change in practice from how we currently operate,
>>> and my ask is that we work together to understand the impact and
>>> concerns.
>>> If you find yourself disagreeing with the goals, let's have that
>>> discussion
>>> instead of arguing about the solution.  If you agree with the goals, but
>>> not the solution, I'd love to hear alternative ideas for how we can
>>> achieve
>>> the outcomes outlined above.
>>>
>>> -- Mike
>>> _______________________________________________
>>> dev-planning mailing list
>>> [hidden email]
>>> https://lists.mozilla.org/listinfo/dev-planning
>>>
>>>
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning
>
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: The future of commit access policy for core Firefox

Mark C么t茅
In reply to this post by Mark C么t茅
On 2017-03-09 8:19 PM, Bobby Holley wrote:

> On Thu, Mar 9, 2017 at 5:08 PM, Mark C么t茅 <[hidden email]> wrote:
>
>> A mistake we made with MozReview was rolling out a new review tool at the
>> same time as the new push-based/autoland automation and workflow. This had
>> a number of repercussions, including requiring users to learn and use a new
>> review tool in order to benefit from autoland and the commit-series
>> approach, but also making it difficult to prioritize fixes and improvements
>> to the various pieces of the system.
>>
>> Having recognized this, we're decoupling this automation and hooking it up
>> to BMO, so we can concentrate on getting it right, since most people are
>> used to using BMO to review patches (this is Project Conduit that I've
>> blogged and posted about in the mozilla.tools newsgroup).
>
>
> This sounds like the right approach.
>
> That said, there can still be hitches in the landing process that are not
> necessarily related to the review tool (recall all the edge cases that bz
> hit a few weeks ago). Decoupling from the review interface is a good first
> step, but building a replacement for {git,hg} push that satisfies
> everyone's use-cases is equally hard.

Indeed, it is.  First, I don't know that Conduit, or any tool, can
satisfy *everyone's* use cases.  But we're certainly going to aim for
the common ones.

The other point I was trying to get across is that by decoupling the
automation, we can focus on it and not split our time between that and
improvements to (and sometimes fixes for) a code-review tool at the same
time.  Also the way we're developing the new system, as separate, small
services, will make the turnaround time on improvements much faster
(working within Review Board's extension system was a terrible idea for
something like this).


Mark


>
> We've also grown the team, which was previously understaffed for the size
>> of the project.  We should have some initial pieces ready to demo in a few
>> weeks, but we won't officially launch it until it's good and ready.
>>
>
> That's great to hear.
>
>
>>
>> (Having a richer and more powerful code-review tool is also still a goal,
>> but we'll deal with that later.)
>>
>> Mark
>>
>>
>> On 2017-03-09 5:59 PM, 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 so critical to
>>> our
>>> productivity as landing code. The only reason more developers aren't
>>> complaining about the MozReview+autoland workflow right now is that it's
>>> optional.
>>>
>>> The busiest and most-productive developers (ehsan, bz, dbaron, etc) tend
>>> not to pay attention to new workflows because they have too much else on
>>> their plate. The onus needs to be on the team deploying this to have the
>>> highest-volume committers using the new system happily and voluntarily
>>> before it becomes mandatory. That probably means that the team should not
>>> have any deadline-oriented incentives to ship it before it's ready.
>>>
>>> Also, getting rid of "r+ with comments" is a non-starter.
>>>
>>> bholley
>>>
>>>
>>> On Thu, Mar 9, 2017 at 1:53 PM, Mike Connor <[hidden email]> 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 number of times, CVS has long since been replaced by
>>>> Mercurial & others, and we've taken some positive steps in terms of
>>>> securing the commit process.  And yet we've never touched the core idea
>>>> of
>>>> granting developers direct commit access to our most important
>>>> repositories.  After a large number of discussions since taking ownership
>>>> over commit policy, I believe it is time for Mozilla to change that
>>>> practice.
>>>>
>>>> Before I get into the meat of the current proposal, I would like to
>>>> outline
>>>> a set of key goals for any change we make.  These goals have been
>>>> informed
>>>> by a set of stakeholders from across the project including the
>>>> engineering,
>>>> security, release and QA teams.  It's inevitable that any significant
>>>> change will disrupt longstanding workflows.  As a result, it is critical
>>>> that we are all aligned on the goals of the change.
>>>>
>>>>
>>>> I've identified the following goals as critical for a responsible commit
>>>> access policy:
>>>>
>>>>
>>>>    - Compromising a single individual's credentials must not be
>>>> sufficient
>>>>    to land malicious code into our products.
>>>>    - Two-factor auth must be a requirement for all users approving or
>>>>    pushing a change.
>>>>    - The change that gets pushed must be the same change that was
>>>> approved.
>>>>    - Broken commits must be rejected automatically as a part of the
>>>> commit
>>>>    process.
>>>>
>>>>
>>>> In order to achieve these goals, I propose that we commit to making the
>>>> following changes to all Firefox product repositories:
>>>>
>>>>
>>>>    - 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 automation misses and handling branch merges.
>>>>    - All other changes will go through an autoland-based workflow.
>>>>       - Developers commit to a staging repository, with scripting that
>>>>       connects the changeset to a Bugzilla attachment, and integrates
>>>> with review
>>>>       flags.
>>>>       - Reviewers and any other approvers interact with the changeset as
>>>>       today (including ReviewBoard if preferred), with Bugzilla flags as
>>>> the
>>>>       canonical source of truth.
>>>>       - Upon approval, the changeset will be pushed into autoland.
>>>>       - If the push is successful, the change is merged to
>>>> mozilla-central,
>>>>       and the bug updated.
>>>>
>>>> I know this is a major change in practice from how we currently operate,
>>>> and my ask is that we work together to understand the impact and
>>>> concerns.
>>>> If you find yourself disagreeing with the goals, let's have that
>>>> discussion
>>>> instead of arguing about the solution.  If you agree with the goals, but
>>>> not the solution, I'd love to hear alternative ideas for how we can
>>>> achieve
>>>> the outcomes outlined above.
>>>>
>>>> -- Mike
>>>> _______________________________________________
>>>> dev-planning mailing list
>>>> [hidden email]
>>>> https://lists.mozilla.org/listinfo/dev-planning
>>>>
>>>>
>> _______________________________________________
>> dev-planning mailing list
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-planning
>>

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: The future of commit access policy for core Firefox

Boris Zbarsky
In reply to this post by Mark C么t茅
On 3/9/17 8:19 PM, Bobby Holley wrote:
> That said, there can still be hitches in the landing process that are not
> necessarily related to the review tool (recall all the edge cases that bz
> hit a few weeks ago).

Most of those were due to opinionated tools that have opinions that
don't match reality, nor each other.

The fewer tools at a time in the mix, the better from that point of view.

That said, I strongly urge people working on these tools to actually
consider the various workflows we use and make sure the tools don't
assume common ones away.  The issues I ran into also had to do with the
opinionated tools having the opinion that certain use cases don't exist.
  Use cases that were brought up as a problem with these tools several
years ago...  This sort of thing is OK for optional-to-use tools, but
less OK for mandatory ones.

> but building a replacement for {git,hg} push that satisfies
> everyone's use-cases is equally hard.

A good start here is establishing what the use-cases are.

-Boris

P.S. I am still thinking about the original policy questions here;
trying not to rathole too much on the mechanism
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: The future of commit access policy for core Firefox

Gijs Kruitbosch ("Hannibal")
In reply to this post by Mike Connor-4
On 09/03/2017 22:59, Bobby Holley wrote:
> Also, getting rid of "r+ with comments" is a non-starter.

+ a lot on this.

I think part of the trust implicit in granting of commit access, and the
reviewer's discretion/trust of the patch author, and said author's
ability to correctly deal with comments without requiring the reviewer
to have another look, mean that removing "r+ with comments" ought not to
be a goal.

If the reviewer doesn't trust the author (from either an ability or
intent perspective) to fix the comments, they shouldn't give "r+ with
nits fixed".

If we don't trust the author to not 'sneak in' unrelated changes off an
r+'d patch, we ought not to give them commit access.

~ Gijs

>
> bholley
>
>
> On Thu, Mar 9, 2017 at 1:53 PM, Mike Connor <[hidden email]> 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 number of times, CVS has long since been replaced by
>> Mercurial & others, and we've taken some positive steps in terms of
>> securing the commit process.  And yet we've never touched the core idea of
>> granting developers direct commit access to our most important
>> repositories.  After a large number of discussions since taking ownership
>> over commit policy, I believe it is time for Mozilla to change that
>> practice.
>>
>> Before I get into the meat of the current proposal, I would like to outline
>> a set of key goals for any change we make.  These goals have been informed
>> by a set of stakeholders from across the project including the engineering,
>> security, release and QA teams.  It's inevitable that any significant
>> change will disrupt longstanding workflows.  As a result, it is critical
>> that we are all aligned on the goals of the change.
>>
>>
>> I've identified the following goals as critical for a responsible commit
>> access policy:
>>
>>
>>    - Compromising a single individual's credentials must not be sufficient
>>    to land malicious code into our products.
>>    - Two-factor auth must be a requirement for all users approving or
>>    pushing a change.
>>    - The change that gets pushed must be the same change that was approved.
>>    - Broken commits must be rejected automatically as a part of the commit
>>    process.
>>
>>
>> In order to achieve these goals, I propose that we commit to making the
>> following changes to all Firefox product repositories:
>>
>>
>>    - 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 automation misses and handling branch merges.
>>    - All other changes will go through an autoland-based workflow.
>>       - Developers commit to a staging repository, with scripting that
>>       connects the changeset to a Bugzilla attachment, and integrates
>> with review
>>       flags.
>>       - Reviewers and any other approvers interact with the changeset as
>>       today (including ReviewBoard if preferred), with Bugzilla flags as
>> the
>>       canonical source of truth.
>>       - Upon approval, the changeset will be pushed into autoland.
>>       - If the push is successful, the change is merged to mozilla-central,
>>       and the bug updated.
>>
>> I know this is a major change in practice from how we currently operate,
>> and my ask is that we work together to understand the impact and concerns.
>> If you find yourself disagreeing with the goals, let's have that discussion
>> instead of arguing about the solution.  If you agree with the goals, but
>> not the solution, I'd love to hear alternative ideas for how we can achieve
>> the outcomes outlined above.
>>
>> -- Mike
>> _______________________________________________
>> dev-planning mailing list
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-planning
>>

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: The future of commit access policy for core Firefox

Gijs Kruitbosch ("Hannibal")
On 10/03/2017 10:58, Gijs Kruitbosch wrote:
> If we don't trust the author to not 'sneak in' unrelated changes off an
> r+'d patch, we ought not to give them commit access.

Addendum: if we feel this sets the bar for commit access too high,
perhaps we need more than 1 level of commit access for this, so that the
tooling enforces trust for the "r+ with comments" case. If I have L3
commit access and review the patch of someone else with L3 commit
access, I don't need to worry about this, but it would be mildly more
palatable for this to be different if I'm reviewing stuff for someone
with L1 commit access.

Either that or the ability for the (L3) reviewer to adjust minor nits
while reviewing, so that the patch doesn't need to go through a whole
other cycle of review. Of course, that then offers the reviewer the
ability to "sneak in" more changes... :-)

~ Gijs


> ~ Gijs
>
>>
>> bholley
>>
>>
>> On Thu, Mar 9, 2017 at 1:53 PM, Mike Connor <[hidden email]> 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 number of times, CVS has long since been replaced by
>>> Mercurial & others, and we've taken some positive steps in terms of
>>> securing the commit process.  And yet we've never touched the core
>>> idea of
>>> granting developers direct commit access to our most important
>>> repositories.  After a large number of discussions since taking
>>> ownership
>>> over commit policy, I believe it is time for Mozilla to change that
>>> practice.
>>>
>>> Before I get into the meat of the current proposal, I would like to
>>> outline
>>> a set of key goals for any change we make.  These goals have been
>>> informed
>>> by a set of stakeholders from across the project including the
>>> engineering,
>>> security, release and QA teams.  It's inevitable that any significant
>>> change will disrupt longstanding workflows.  As a result, it is critical
>>> that we are all aligned on the goals of the change.
>>>
>>>
>>> I've identified the following goals as critical for a responsible commit
>>> access policy:
>>>
>>>
>>>    - Compromising a single individual's credentials must not be
>>> sufficient
>>>    to land malicious code into our products.
>>>    - Two-factor auth must be a requirement for all users approving or
>>>    pushing a change.
>>>    - The change that gets pushed must be the same change that was
>>> approved.
>>>    - Broken commits must be rejected automatically as a part of the
>>> commit
>>>    process.
>>>
>>>
>>> In order to achieve these goals, I propose that we commit to making the
>>> following changes to all Firefox product repositories:
>>>
>>>
>>>    - 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 automation misses and handling branch merges.
>>>    - All other changes will go through an autoland-based workflow.
>>>       - Developers commit to a staging repository, with scripting that
>>>       connects the changeset to a Bugzilla attachment, and integrates
>>> with review
>>>       flags.
>>>       - Reviewers and any other approvers interact with the changeset as
>>>       today (including ReviewBoard if preferred), with Bugzilla flags as
>>> the
>>>       canonical source of truth.
>>>       - Upon approval, the changeset will be pushed into autoland.
>>>       - If the push is successful, the change is merged to
>>> mozilla-central,
>>>       and the bug updated.
>>>
>>> I know this is a major change in practice from how we currently operate,
>>> and my ask is that we work together to understand the impact and
>>> concerns.
>>> If you find yourself disagreeing with the goals, let's have that
>>> discussion
>>> instead of arguing about the solution.  If you agree with the goals, but
>>> not the solution, I'd love to hear alternative ideas for how we can
>>> achieve
>>> the outcomes outlined above.
>>>
>>> -- Mike
>>> _______________________________________________
>>> dev-planning mailing list
>>> [hidden email]
>>> https://lists.mozilla.org/listinfo/dev-planning
>>>
>

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: The future of commit access policy for core Firefox

Masatoshi Kimura
In reply to this post by Mike Connor-4
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 only to contribute
Mozilla? What's the next?

--
[hidden email]
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: The future of commit access policy for core Firefox

Axel Hecht
In reply to this post by Mike Connor-4
Am 09.03.17 um 22:53 schrieb Mike Connor:

> (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 been replaced by
> Mercurial & others, and we've taken some positive steps in terms of
> securing the commit process.  And yet we've never touched the core idea of
> granting developers direct commit access to our most important
> repositories.  After a large number of discussions since taking ownership
> over commit policy, I believe it is time for Mozilla to change that
> practice.
>
> Before I get into the meat of the current proposal, I would like to outline
> a set of key goals for any change we make.  These goals have been informed
> by a set of stakeholders from across the project including the engineering,
> security, release and QA teams.  It's inevitable that any significant
> change will disrupt longstanding workflows.  As a result, it is critical
> that we are all aligned on the goals of the change.
>
>
> I've identified the following goals as critical for a responsible commit
> access policy:
>
>
>     - Compromising a single individual's credentials must not be sufficient
>     to land malicious code into our products.
>     - Two-factor auth must be a requirement for all users approving or
>     pushing a change.
>     - The change that gets pushed must be the same change that was approved.
>     - Broken commits must be rejected automatically as a part of the commit
>     process.

<--->

> I know this is a major change in practice from how we currently operate,
> and my ask is that we work together to understand the impact and concerns.
> If you find yourself disagreeing with the goals, let's have that discussion
> instead of arguing about the solution.  If you agree with the goals, but
> not the solution, I'd love to hear alternative ideas for how we can achieve
> the outcomes outlined above.
>

Hi,

I actually have issues with the goals, so I cut out the impl parts.

Here's goals that I'd add to be explicitly stated:

- We want as many people as possible to change the Firefox code base.
- We want to be able to change the Firefox code base going to release
audience as quickly as possible.

How those goals or technical decisions work in favor of goals is really
hard to evaluate without some threat models.

Also, you've been vague on which repositories you intend to cover, and I
also think that that depends on the threat models.

So, along the lines of David's ask in .platform, I'd really appreciate
to get more details on the problems we're hoping to mitigate.

Axel
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: The future of commit access policy for core Firefox

mhoye


On 2017-03-10 7:49 AM, Axel Hecht wrote:
> - We want as many people as possible to change the Firefox code base.

For whatever it's worth, I want the Firefox development process to be as
accessible and participatory as possible to as many people as possible,
but that's not quite the same as "as many people as possible can change
codebase".  Automation that removes unnecessary complexity is a big help
in reducing barriers to participation.

- mhoye
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: The future of commit access policy for core Firefox

Ehsan Akhgari
On Fri, Mar 10, 2017 at 8:49 AM, Mike Hoye <[hidden email]> wrote:

>
>
> On 2017-03-10 7:49 AM, Axel Hecht wrote:
>
>> - We want as many people as possible to change the Firefox code base.
>>
>
> For whatever it's worth, I want the Firefox development process to be as
> accessible and participatory as possible to as many people as possible, but
> that's not quite the same as "as many people as possible can change
> codebase".  Automation that removes unnecessary complexity is a big help in
> reducing barriers to participation.
>

Automation that adds unnecessary complexity is a big hindrance in
participation also.  Maybe there is a good reason why we should be doing
that, but the proposal doesn't really mention what problem it's actually
trying to solve besides vague mentions of the stakeholders settings these
four goals.

For example, what problem is the first goal solving? ("Compromising a
single individual's credentials must not be sufficient to land malicious
code into our products.")  Does anyone believe that is the only way you can
put malicious code into Firefox, whereas anyone can submit malicious code
under a pseudonym in Bugzilla and we know from past experience times and
times again that mistakes will remain uncaught during review and testing
due to the nature of software?

--
Ehsan
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: The future of commit access policy for core Firefox

Ben Hearsum-2
In reply to this post by mhoye
On 2017-03-10 09:39 AM, Ehsan Akhgari wrote:

> On Fri, Mar 10, 2017 at 8:49 AM, Mike Hoye <[hidden email]> wrote:
>
>>
>>
>> On 2017-03-10 7:49 AM, Axel Hecht wrote:
>>
>>> - We want as many people as possible to change the Firefox code base.
>>>
>>
>> For whatever it's worth, I want the Firefox development process to be as
>> accessible and participatory as possible to as many people as possible, but
>> that's not quite the same as "as many people as possible can change
>> codebase".  Automation that removes unnecessary complexity is a big help in
>> reducing barriers to participation.
>>
>
> Automation that adds unnecessary complexity is a big hindrance in
> participation also.  Maybe there is a good reason why we should be doing
> that, but the proposal doesn't really mention what problem it's actually
> trying to solve besides vague mentions of the stakeholders settings these
> four goals.
>
> For example, what problem is the first goal solving? ("Compromising a
> single individual's credentials must not be sufficient to land malicious
> code into our products.")  Does anyone believe that is the only way you can
> put malicious code into Firefox, whereas anyone can submit malicious code
> under a pseudonym in Bugzilla and we know from past experience times and
> times again that mistakes will remain uncaught during review and testing
> due to the nature of software?

I _think_ the threat model here is a bad actor or someone with a highly
privileged account being coerced into committing something bad.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
1234