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 always been. We've evol
> 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
> rebase? Do you need to get
A bit off topic
On 03/13/2017 04:37 PM, David Burns wrote:
Regarding burden on reviewers, the comments in this thread just highlight
how broken our current process is by having to flag individual people for
reviews. This leads to the a handful of people doing 50%+ of reviews on the
code.
Unfor
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 <
governance@lists.mozilla.org> 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 lands.
ie. "r+, fix typo in comment be
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 reviewe
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 <
governance@lists.mozilla.org> wrote:
I'd be ok to do a quick r+ if interdiff was working w
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 <
>> governance@lists.mozilla.org> wrote:
>>>
>>> I'd be ok to do a quick r+ if interdiff was working well.
>>
>> Depending on the relativ
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 handle
> LGTM
> > w
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
b
+1 for these proposed changes
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
On 03/11/2017 08:23 AM, Nicholas Nethercote wrote:
On Sat, Mar 11, 2017 at 2:23 PM, smaug via governance <
governance@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
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
West Coast, thank
you very
On Sat, Mar 11, 2017 at 2:23 PM, smaug via governance <
governance@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 the
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
On 03/11/2017 05:23 AM, smaug 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 flipping on an MVP and dealing with the rest in
followup bugs isn't g
On Fri, Mar 10, 2017 at 7:23 PM, smaug via governance <
governance@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
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 so
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 o
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 after the creation of th
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.
(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
22 matches
Mail list logo
