Re: The future of commit access policy for core Firefox

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. >

Re: The future of commit access policy for core Firefox

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

Re: The future of commit access policy for core Firefox

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

Re: The future of commit access policy for core Firefox

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

Re: The future of commit access policy for core Firefox

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

Re: The future of commit access policy for core Firefox

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: The future of commit access policy for core Firefox

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

Re: The future of commit access policy for core Firefox

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

Re: The future of commit access policy for core Firefox

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

Re: Please write good commit messages before asking for code review

On Friday 2017-03-10 07:46 +0900, Mike Hommey wrote: > I'd argue some of this commit message should actually be in the > code comment. Yes. The commit message should be largely about *change* (how this revision of code is different from earlier ones), that is, what is changing, why it's

Re: Please write good commit messages before asking for code review

On Thu, Mar 09, 2017 at 05:50:36PM -0500, Ehsan Akhgari wrote: > > On the subject of long commit messages, here's a commit message I wrote > > that had 3 paragraphs to explain a patch that just changed a 0 to a 1: > > https://hg.mozilla.org/integration/autoland/rev/bf059ec2bdc9 > > I think the

Re: Please write good commit messages before asking for code review

On Thu, Mar 9, 2017 at 2:53 PM, Ben Kelly wrote: > > > On Thu, Mar 9, 2017 at 5:48 PM, Eric Rescorla wrote: > >> >> >> On Thu, Mar 9, 2017 at 2:43 PM, Ben Kelly wrote: >> >>> (Just continuing the thread here.) >>> >>> Personally I prefer

Re: The future of commit access policy for core Firefox

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

Re: Please write good commit messages before asking for code review

On 3/9/17 5:53 PM, Ben Kelly wrote: Right now our security bug process asks about the commit message and if it "paints a target" on the patch. It asks this: Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem? I always

Re: The future of commit access policy for core Firefox

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

Re: Please write good commit messages before asking for code review

On 2017-03-09 5:48 PM, Eric Rescorla wrote: > > > On Thu, Mar 9, 2017 at 2:43 PM, Ben Kelly > wrote: > > On Thu, Mar 9, 2017 at 5:35 PM, Mike Hommey > wrote: > > > On Thu, Mar 09, 2017

Re: Please write good commit messages before asking for code review

On Thu, Mar 9, 2017 at 5:48 PM, Eric Rescorla wrote: > > > On Thu, Mar 9, 2017 at 2:43 PM, Ben Kelly wrote: > >> (Just continuing the thread here.) >> >> Personally I prefer looking at the bug for the full context and single >> point of truth. Also, security

Re: Please write good commit messages before asking for code review

On 2017-03-09 5:35 PM, Mike Hommey wrote: > On Thu, Mar 09, 2017 at 02:46:53PM -0500, Ehsan Akhgari wrote: >> I review a large number of patches on a typical day, and usually I have to >> spend a fair amount of time to just understand what the patch is doing. As >> the patch author, you can do a

Re: Please write good commit messages before asking for code review

On 2017-03-09 5:07 PM, Andrew McCreight wrote: > On Thu, Mar 9, 2017 at 1:55 PM, Nicholas Alexander > wrote: > >> On Thu, Mar 9, 2017 at 1:48 PM, Boris Zbarsky wrote: >> >>> On 3/9/17 4:35 PM, Eric Rescorla wrote: >>> I'm in favor of good commit

Re: Please write good commit messages before asking for code review

On Thu, Mar 9, 2017 at 2:43 PM, Ben Kelly wrote: > On Thu, Mar 9, 2017 at 5:35 PM, Mike Hommey wrote: > > > On Thu, Mar 09, 2017 at 02:46:53PM -0500, Ehsan Akhgari wrote: > > > I review a large number of patches on a typical day, and usually I have > > to

Re: Please write good commit messages before asking for code review

On Thu, Mar 9, 2017 at 5:43 PM, Ben Kelly wrote: > Personally I prefer looking at the bug for the full context and single > point of truth. Also, security bugs typically can't have extensive commit > messages and moving a lot of context to commit messages might paint a >

Re: Please write good commit messages before asking for code review

On Thu, Mar 09, 2017 at 02:07:51PM -0800, Andrew McCreight wrote: > On Thu, Mar 9, 2017 at 1:55 PM, Nicholas Alexander > wrote: > > > On Thu, Mar 9, 2017 at 1:48 PM, Boris Zbarsky wrote: > > > > > On 3/9/17 4:35 PM, Eric Rescorla wrote: > > > > > >> I'm

Re: Please write good commit messages before asking for code review

On Thu, Mar 9, 2017 at 5:35 PM, Mike Hommey wrote: > On Thu, Mar 09, 2017 at 02:46:53PM -0500, Ehsan Akhgari wrote: > > I review a large number of patches on a typical day, and usually I have > to > > spend a fair amount of time to just understand what the patch is doing. > As

Re: Please write good commit messages before asking for code review

On Thu, Mar 09, 2017 at 02:46:53PM -0500, Ehsan Akhgari wrote: > I review a large number of patches on a typical day, and usually I have to > spend a fair amount of time to just understand what the patch is doing. As > the patch author, you can do a lot to help make this easier by *writing >

Re: Sheriff Highlights and Summary in February 2017

I don't know that it's useful to modify your report if you're confident in your estimates below. Thanks for the additional information. Lawrence On Tue, Mar 7, 2017 at 4:03 AM, Carsten Book wrote: > Hi Lawrence, > > most (i would say 95 %) of the backouts are for Code issues

Re: Please write good commit messages before asking for code review

On Thu, Mar 9, 2017 at 2:07 PM, Andrew McCreight wrote: > On Thu, Mar 9, 2017 at 1:55 PM, Nicholas Alexander > > wrote: > > > On Thu, Mar 9, 2017 at 1:48 PM, Boris Zbarsky wrote: > > > > > On 3/9/17 4:35 PM, Eric Rescorla

Re: Please write good commit messages before asking for code review

On Thu, Mar 9, 2017 at 1:55 PM, Nicholas Alexander wrote: > On Thu, Mar 9, 2017 at 1:48 PM, Boris Zbarsky wrote: > > > On 3/9/17 4:35 PM, Eric Rescorla wrote: > > > >> I'm in favor of good commit messages, but I would note that current m-c > >>

Re: Please write good commit messages before asking for code review

Oops just saw this after I posted separately about this feature. Yeah, I agree it's a bit confusing. We have a few ideas for making this better differentiated; will open a bug. Mark On 2017-03-09 3:29 PM, Kyle Machulis wrote: This has actually been confusing me in reviews, since the

Re: Project Stockwell (reducing intermittents) - March 2017 update

> It'd make me feel slightly less sad that we're disabling tests > that do their job 90% of the time... The way I interpret a test failing 10% of the time is that either it has already done its job to indicate a problem in the product, or the test is not doing its job. Either way, if it is not

Re: Please write good commit messages before asking for code review

On 2017-03-09 4:48 PM, Boris Zbarsky wrote: On 3/9/17 4:35 PM, Eric Rescorla wrote: I'm in favor of good commit messages, but I would note that current m-c convention really pushes against this, because people seem to feel that commit messages should be one line. They feel wrong, and we

Re: Please write good commit messages before asking for code review

On Thu, Mar 9, 2017 at 1:48 PM, Boris Zbarsky wrote: > On 3/9/17 4:35 PM, Eric Rescorla wrote: > >> I'm in favor of good commit messages, but I would note that current m-c >> convention really pushes against this, because people seem to feel that >> commit messages should be

Re: Please write good commit messages before asking for code review

On Thursday 2017-03-09 13:35 -0800, Eric Rescorla wrote: > I'm in favor of good commit messages, but I would note that current m-c > convention really pushes against this, because people seem to feel that > commit messages should be one line. Not sure what to do about that, > but thought I would

The future of commit access policy for core Firefox

(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

Re: Please write good commit messages before asking for code review

On 3/9/17 4:35 PM, Eric Rescorla wrote: I'm in favor of good commit messages, but I would note that current m-c convention really pushes against this, because people seem to feel that commit messages should be one line. They feel wrong, and we should tell them so. ;) The first line should

Re: Is there a way to improve partial compilation times?

zbranie...@mozilla.com writes: > * I still have only 8GB of ram which is probably the ultimate > limiting factor You are right here. RAM is required not only for link time, but also when compiling several large unified files at a time (though perhaps this is not so significant with only 4

Re: Please write good commit messages before asking for code review

I'm in favor of good commit messages, but I would note that current m-c convention really pushes against this, because people seem to feel that commit messages should be one line. Not sure what to do about that, but thought I would mention it. -Ekr On Thu, Mar 9, 2017 at 12:10 PM, Boris Zbarsky

Re: Is there a way to improve partial compilation times?

Reporting first results. We got an icecream setup in SF office and I was able to plug myself into it and got a icecc+ccache+gcc combo with a fresh debug build in <30 min. On top of that, I had low load on my machine, which is nice as in the meantime I was able to work on other things. Now,

Re: Please write good commit messages before asking for code review

This has actually been confusing me in reviews, since the commit-message looks like another file in the diff. Not sure of a better way to show this isn't going to be a file when checked in, but with the way it's shown as part of the change set in the patch right now, it's hard to discern. On Thu,

Re: Please write good commit messages before asking for code review

On 3/9/17 2:46 PM, Ehsan Akhgari wrote: Starting now, I'm going to try out a new practice for a while: I'm going to first review the commit message of all patches, and if I can't understand what the patch does by reading the commit message before reading any of the code, I'll r- and ask for

Re: Project Stockwell (reducing intermittents) - March 2017 update

On 09/03/17 19:53, Milan Sreckovic wrote: Not a reply to this message, just continuing the thread. I'd like to see us run all the intermittently disabled tests once a ... week, say, or at some non-zero frequency, and automatically re-enable the tests that magically get better. I have a feeling

Re: Please write good commit messages before asking for code review

Incidentally, MozReview now allows you to provide feedback on the commit message in the diffviewer. On Mar 9, 2017 2:47 PM, "Ehsan Akhgari" wrote: > I review a large number of patches on a typical day, and usually I have to > spend a fair amount of time to just

Re: Project Stockwell (reducing intermittents) - March 2017 update

Not a reply to this message, just continuing the thread. I'd like to see us run all the intermittently disabled tests once a ... week, say, or at some non-zero frequency, and automatically re-enable the tests that magically get better. I have a feeling that some intermittent failures get

Please write good commit messages before asking for code review

I review a large number of patches on a typical day, and usually I have to spend a fair amount of time to just understand what the patch is doing. As the patch author, you can do a lot to help make this easier by *writing better commit messages*. Starting now, I'm going to try out a new practice

Re: Project Stockwell (reducing intermittents) - March 2017 update

A lot of great discussion here, thanks everyone for taking some time out of your day to weigh in on this subject. There are slight differences between a bug being filed and actively working on the bug once it crosses our threshold of 30 failures/week- I want to discuss when we have looked at

Re: Is there a way to improve partial compilation times?

On Tue, Mar 7, 2017 at 5:40 PM, Randell Jesup wrote: > >On 07/03/17 20:29, zbranie...@mozilla.com wrote: > > > >> I was just wondering if really two days of patches landing in Gecko > should result > >> in what seems like basically full rebuild. > >> > >> A clean build

Re: Project Stockwell (reducing intermittents) - March 2017 update

On Wed, Mar 8, 2017 at 6:02 PM, L. David Baron wrote: > As of 5 days ago, "Treeherder Bug Filer" was not using BUG_COMPONENT > information. I say this based on: > https://bugzilla.mozilla.org/show_bug.cgi?id=1344304 > being filed in Core :: Layout despite: > > $ ./mach

Re: Is there a way to improve partial compilation times?

I'm pretty sure that by the time we're reaching that number of cores we'll be blocked on preprocessing, as preprocessing occurs on the local machine (where the header files are), and on network I/O. I imagine that peak efficiency is well below 2k machines. In addition, there's some unavoidable

Quantum Flow Engineering Newsletter #1

Hi everyone, A while ago a number of engineers including myself started to look into a performance project that turned into Quantum Flow. The focus of the project is finding and prioritising the issues across the browser so we will need help from many of you to get them fixed. I’m planning to

Re: Is there a way to improve partial compilation times?

On Thu, Mar 09, 2017 at 07:45:13AM -0500, Ted Mielczarek wrote: > On Wed, Mar 8, 2017, at 05:43 PM, Ehsan Akhgari wrote: > > On 2017-03-08 11:31 AM, Simon Sapin wrote: > > > On 08/03/17 15:24, Ehsan Akhgari wrote: > > >> What we did in the Toronto office was walked to people who ran Linux on > >

Re: Is there a way to improve partial compilation times?

On Wed, Mar 8, 2017, at 05:43 PM, Ehsan Akhgari wrote: > On 2017-03-08 11:31 AM, Simon Sapin wrote: > > On 08/03/17 15:24, Ehsan Akhgari wrote: > >> What we did in the Toronto office was walked to people who ran Linux on > >> their desktop machines and installed the icecream server on their > >>

Re: Is there a way to improve partial compilation times?

On Thu, Mar 9, 2017, at 07:42 AM, Wei-Cheng Pan wrote: > We are using icecream in the Taipei office too, and it is a big enhance. > Sadly when we tried to use it on Mac OS, we always got wrong stack > information. > I've read the article on MDN, seems it's related to a compiler flag >

Re: Startup JS debugging (sometimes) possible via Browser Toolbox

You almost completely resolved the 4-year-old bug 814298, yay! I now wonder if this makes it easier to improve mochitest debugging per bug 929535. On Wed, Mar 8, 2017 at 9:22 PM, Kris Maglione wrote: > On Wed, Mar 08, 2017 at 01:09:10PM -0600, J. Ryan Stinnett wrote: > >>