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
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 to try multiple times
I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1241535 to determine if we
can have a more streamlined method for collecting profiles.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
As someone who spends a lot of time trying to understand code that I
know nothing about, I find it very frustrating that Mozilla code
frequently is written with absolutely no comment on why that code
exists, or what it is trying to do.
Today's example: SharedCertVerifier.h
Inquiring minds wan
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 I know
> nothing
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 compone
I'll point out that the downside of using a google doc like this is that
it's only accessible to Mozilla employees.
Cheers,
Josh
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
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 only accessible to Mozill
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.
>
> Thanks,
>
> -- Em
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 wrote:
>> I understand, and
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
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 any
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 via SSH, as of a few
> 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 definitely one of the improv
On Thu, Jan 21, 2016 at 6:35 PM, Gregory Szorc wrote:
>
> I've gotten into the habit of just landing things if I r+ them and I think
> they are ready to land. This has startled a few people because it is a major
> role reversal of how we've done things for years. (Typically we require the
> patch
>
> 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 p
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 further after
> getting r
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
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
> 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 land commits from t
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 to
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
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
> people or unilaterally imp
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 a
24 matches
Mail list logo
