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 ma
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 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 effective.
> >
>
> To my knowledge, mconnor's proposal
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 policy. Was there a behavior
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 minu
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 discussio
> 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 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
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:
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
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/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 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
> >>> pushing a change.
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?
>>
>> Previously
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 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 <
>> governa...@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
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 on
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
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 <
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 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 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
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 int
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 o
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 buy
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 l
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
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.
>
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
di
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 num
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 automatio
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 fr
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
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
exampl
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 the Mozilla Project, commit acce
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
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.
42 matches
Mail list logo
