Adding new jobs to pushes in better shape

I've spent the last two days fixing most issues affecting adding jobs on Treeherder. I believe it is now working properly. You don't need to try multiple times. Remember: * this does not work with TaskCluster jobs [1] * if you own the push, you can add jobs * if you use and @mozilla.com, you have

Re: Adding new jobs to pushes in better shape

Thanks! I just used this on inbound and it seems to be working well. :) On Thu, Jan 21, 2016 at 9:26 AM, Armen Zambrano G. wrote: > I've spent the last two days fixing most issues affecting adding jobs on > Treeherder. > I believe it is now working properly. > You don't need

[Responses Needed by Jan 27] Identifying Owners of Bugzilla Components in Firefox, Toolkit, and Core

The short version: we believe that the number of outstanding bugs in a component is the best metric we have of the overall health and quality of that component. We will test this belief by dramatically improving the efficiency of ingest and processing of new bugs, and would like two to four

Re: [Responses Needed by Jan 27] Identifying Owners of Bugzilla Components in Firefox, Toolkit, and Core

I understand, and if non-mozilla.com community members need access, email me or request access from inside the sheet. Thanks, -- Emma On Thu, Jan 21, 2016 at 2:31 PM, Josh Matthews wrote: > I'll point out that the downside of using a google doc like this is that > it's

Re: [Responses Needed by Jan 27] Identifying Owners of Bugzilla Components in Firefox, Toolkit, and Core

Is there any reason not to make the link publicly accessible? Then no-one needs to request access. On Thu, Jan 21, 2016 at 2:37 PM, Emma Humphries wrote: > I understand, and if non-mozilla.com community members need access, > email me or request access from inside the sheet. >

Re: [Responses Needed by Jan 27] Identifying Owners of Bugzilla Components in Firefox, Toolkit, and Core

I was about to mention. If you click on "Advanced" in the sharing dialog, you can switch to anyone with the link (on the web). Philipp On 1/21/16 11:44 PM, Dave Townsend wrote: > Is there any reason not to make the link publicly accessible? Then > no-one needs to request access. > > On Thu, Jan

Re: [Responses Needed by Jan 27] Identifying Owners of Bugzilla Components in Firefox, Toolkit, and Core

Good point. I'll make the link accessible to all. -- Emma On Thu, Jan 21, 2016 at 2:44 PM, Dave Townsend wrote: > Is there any reason not to make the link publicly accessible? Then > no-one needs to request access. > > On Thu, Jan 21, 2016 at 2:37 PM, Emma Humphries

Re: Just Autoland It

Should we just add a "and land it" checkbox to the review page, maybe disabled if there are still open issues? On Thu, Jan 21, 2016 at 6:35 PM, Gregory Szorc wrote: > If you have level 3 source code access (can push to central, inbound, > fx-team) and have pushed to MozReview

Re: Just Autoland It

> On Jan 21, 2016, at 19:00, Dave Townsend wrote: > > Should we just add a "and land it" checkbox to the review page, maybe > disabled if there are still open issues? We talked about improving the review finalization overlay window at our meeting today and this is

Just Autoland It

If you have level 3 source code access (can push to central, inbound, fx-team) and have pushed to MozReview via SSH, as of a few weeks ago you can now land commits from the "Automation" drop down menu on MozReview. (Before only the review request author could trigger autoland.) This means that

Re: Just Autoland It

On Thu, Jan 21, 2016 at 10:37 PM, David Rajchenbach-Teller < dtel...@mozilla.com> wrote: > That sounds like it's going to break stuff. > > Reviewers frequently ask me to change stuff during reviews. I don't > re-run all the tests on all the platforms after every single round of > review. Once in

Re: Just Autoland It

> > Both of these behaviours are incompatible with reviewer-initiated landing. > I've fallen on both sides of this particular fence; sometimes I want to fire-and-forget a patch, and sometimes I still want to digest further after getting review (or I know a piece of work is incomplete and further

Splitting inner and outer windows

Early in the next release cycle I plan to land a patch that will remove nsPIDOMWindow in favor of two separate types for inner and outer windows (fittingly, called nsPIDOMWindowInner/nsPIDOMWindowOuter) I'll also make changes to the XPIDL interface hierarchy (effectively removing nsIDOMWindow and

Re: Just Autoland It

On Jan 21, 2016, at 21:25, Richard Newman wrote: >> Both of these behaviours are incompatible with reviewer-initiated landing. > > I've fallen on both sides of this particular fence; sometimes I want to > fire-and-forget a patch, and sometimes I still want to digest

Re: Just Autoland It

> On Jan 21, 2016, at 21:46, Mike Hommey wrote: > >> On Thu, Jan 21, 2016 at 06:35:08PM -0800, Gregory Szorc wrote: >> If you have level 3 source code access (can push to central, inbound, >> fx-team) and have pushed to MozReview via SSH, as of a few weeks ago you >> can now

Re: Just Autoland It

On Thu, Jan 21, 2016 at 06:35:08PM -0800, Gregory Szorc wrote: > If you have level 3 source code access (can push to central, inbound, > fx-team) and have pushed to MozReview via SSH, as of a few weeks ago you > can now land commits from the "Automation" drop down menu on MozReview. > (Before only

Re: Just Autoland It

That sounds like it's going to break stuff. Reviewers frequently ask me to change stuff during reviews. I don't re-run all the tests on all the platforms after every single round of review. Once in a while, the changes end up breaking stuff which I need to fix – generally trivial stuff that I can

Re: Just Autoland It

Like Greg, I'm a big fan of reviewer-lands-if-ready. It's a huge simplification of workflow, saves developers time, and lets machines do work instead of humans. That said, I don't think we should be surprising people or unilaterally imposing changes to their workflow. The best way to do this is

Re: Just Autoland It

On Thu, Jan 21, 2016 at 10:37 PM, Mike Connor wrote: > Like Greg, I'm a big fan of reviewer-lands-if-ready. It's a huge > simplification of workflow, saves developers time, and lets machines do > work instead of humans. That said, I don't think we should be surprising >

Re: Can we have a policy (in the style guide?) that classes need a basic description of what they are about?

Reviewers should always require appropriate in-code documentation. That said, I don't think the style guide is the appropriate place to solve this problem. On Thu, Jan 21, 2016 at 10:42 AM, R Kent James wrote: > As someone who spends a lot of time trying to understand code that