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 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: 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 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
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
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
Re: Sheriff Highlights and Summary in February 2017
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