Re: The future of commit access policy for core Firefox

[smaug]

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 by 24 hours or even a whole weekend.


The final r+, if it is just cosmetic changes wouldn't need to be done by the 
same reviewer.

Perhaps we shouldn't even call the last step a review. It would be "ok-to-land".
r+ without asking any changes would implicitly contain that "ok-to-land".
(if rebasing causes some changes, that would then need explicit "ok-to-land")





In general there seems to be a large amount of support in this thread for
continuing to allow the r+-with-minor-fixes option.


Yeah. I don't object that, but I also think that having final approval to land 
the patch might not really be that bad
(assuming the tools are working well enough).



Nick



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

Re: The future of commit access policy for core Firefox

[gsquelart]

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 the relative timezones of the reviewer and reviewee, that
> > could delay landing by 24 hours or even a whole weekend.
> >
> The final r+, if it is just cosmetic changes wouldn't need to be done by the 
> same reviewer.
> 
> Perhaps we shouldn't even call the last step a review. It would be 
> "ok-to-land".
> r+ without asking any changes would implicitly contain that "ok-to-land".
> (if rebasing causes some changes, that would then need explicit "ok-to-land")
> 
> 
> 
> 
> > In general there seems to be a large amount of support in this thread for
> > continuing to allow the r+-with-minor-fixes option.
> 
> Yeah. I don't object that, but I also think that having final approval to 
> land the patch might not really be that bad
> (assuming the tools are working well enough).
> 
> >
> > Nick

If we really want to enforce a final review to prevent unwanted code to land, 
Mozilla (as a whole) will incur some costs: Reviewers spending time 
re-reviewing; delays to land (worse across tz, and which could result in the 
need to rebase again, and therefore another round of ok-to-land); and mounting 
anger at all these papercuts.

So if Mozilla is really committed to this solution, and is ready to bear the 
associated financial costs, I would suggest we recruit people who would do just 
these tasks! Could be existing sheriffs, and/or volunteering peers, and/or new 
staff with distinct job descriptions.

Hopefully they'd rubber-stamp 99% of last-minute changes, and only the more 
complex changes would be referred back to the author and reviewer.
As a bonus they could also handle trivial autoland merge issues.

In the end it should cost a similar amount of money, but would lessen the other 
costs (delays and frustration).


And while I've got the mic, a small suggestion for mozreview to help with some 
of this: We need a way for the author to add a comment explaining what was done 
between pushes (rebase, nit-fixing, other notes to reviewer, etc.); this 
comment would only appear in Bugzilla and mozreview, not in the actual patch 
commit description.
(Could be a paragraph starting with "notes-to-reviewer:", to be removed before 
autolanding.)

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

Re: The future of commit access policy for core Firefox

[Cameron Kaiser]

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
build time. Now do I have to buy a smartphone only to contribute
Mozilla? What's the next?


I actually use a Perl script to do HOTP. And there are things like 
Firekey. No mobile device necessary.


Cameron Kaiser
tier-3-2-1-contact!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Sheriff Highlights and Summary in February 2017

[jmaher]

On Friday, March 10, 2017 at 3:46:14 PM UTC-5, Kris Maglione wrote:
> On Fri, Mar 10, 2017 at 01:55:40PM +, David Burns wrote:
> >I went back and did some checks with autoland to servo and the results are
> >negligible. So from 01 February 2017 to 10 March 2017 (as of sending this
> >email). I have removed merge commits from the numbers.
> >
> >Autoland:
> >Total Servo Sync Pushes: 152
> >Total Pushes: 1823
> >Total Backouts: 144
> >Percentage of backouts: 7.8990674712
> >Percentage of backouts without Servo: 8.61759425494
> >
> >Mozilla-Inbound:
> >Total Pushes: 1472
> >Total Backouts: 166
> >Percentage of backouts: 11.277173913
> 
> Is there any way you can get these numbers in terms of patches, rather than 
> pushes? Or, ideally, in terms of bugs landed and backed out? Pushes to 
> inbound 
> still often have patches for more than one bug, so if 4 bugs bets pushed to 
> inbound in one push, and 4 land on autoland as separate pushes, and one gets 
> backed out from each branch, the comparison isn't very useful.

I have been asking the same question and from some initial data, it looks like 
we would have 2075 bugs changed with 166 backouts, or a 8.0% backout rate.  I 
think David is working on validating this data, but to me it shows that code 
quality is the same between branches, we are just landing more bugs on inbound.

There is more guess work for the sheriffs when it comes to backing out things 
with multibug pushes, I would be curious how many times (in the last few 
months) we have had a backout on inbound that didn't fix the problem due to 
multi bug pushes.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: The future of commit access policy for core Firefox

[Gabor Krizsanits]

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 much for bringing up the timezone argument. r+-with-minor-fixes is
an absolute must for
some of us.

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