On Tuesday 2013-11-05 14:44 +, David Burns wrote:
> We appear to be doing 1 backout for every 15 pushes on a rough
> average[4]. This number I am sure you can all agree is far too high
> especially if we think about the figures that John O'Duinn
> suggests[5] for the cost of each push for runni
On Tue, Nov 5, 2013 at 7:10 AM, James Graham wrote:
>
> So, as far as I can tell that the heart of the problem is that the
> end-to-end time for the build+test infrastructure is unworkably slow. I
> understand that waiting half a dozen hours — a significant fraction of a
> work day — for a try run
On 11/5/13 4:49 PM, Andreas Gal wrote:
> If you can access the remaining battery status of a large enough
> population over time it should be easy to use telemetry to measure
> this pre and post patch.
>
> Andreas
>
> Sent from Mobile.
As it turns out, the platform currently offers an abstract n
It would be best not to share yet, because as Lawrence noted, the videos are
not live yet. I've already began recording them though.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On 05/11/2013 18:11, Steve Fink wrote:
These stats are *awesome*! I've been wanting them for a long time, but
never got around to generating them myself. Can we track these on an
ongoing basis?
Sure! Since we need to be working on the engineering productivity as a
whole I think this could be a
- Original Message -
> Added to the etherpad too but here's the list I have so far.
>
> I started a github project a month or so ago here: (Still pretty early)
> https://github.com/bbondy/codefirefox/
>
> And here are some videos, layout will be changing, that's just temporary:
> http://c
On Nov 3, 2013, at 12:27 PM, Robert O'Callahan wrote:
> On Sun, Nov 3, 2013 at 1:24 PM, wrote:
>
>> Added to the etherpad too but here's the list I have so far.
>>
>> I started a github project a month or so ago here: (Still pretty early)
>> https://github.com/bbondy/codefirefox/
>>
>> And h
On 11/02/2013 05:24 PM, bbo...@gmail.com wrote:
> 2.0 Creating a .mozconfig file
Make that creating a "mozconfig" file. Both names are supported, but mozconfig
is preferable: it's visible in directory listings and such, and it's easier to
create on Windows.
Jeff
_
On 15:10, Tue, 05 Nov, James Graham wrote:
On 05/11/13 14:57, Kyle Huey wrote:
On Tue, Nov 5, 2013 at 10:44 PM, David Burns wrote:
We appear to be doing 1 backout for every 15 pushes on a rough average[4].
This number I am sure you can all agree is far too high especially if we
think about th
On 11/05/2013 01:49 PM, Chris Peterson wrote:
On 11/5/13, 7:10 AM, James Graham wrote:
Wht data do we currently have about why the wait time is so long? If
this data doesn't exist, can we start to collect it? Are there easy wins
to be had, or do we need to think about restructuring the way that
On 11/5/13, 2:00 AM, Neil wrote:
Gijs Kruitbosch wrote:
I don't have all my patches applied all the time. If I work on
something, leave it for 2 weeks, and qpush it again, I usually get to
do the "fix all the .rej" dance.
That's an interesting use case. If changeset evolution replaces mq you
On 11/5/13, 7:10 AM, James Graham wrote:
Wht data do we currently have about why the wait time is so long? If
this data doesn't exist, can we start to collect it? Are there easy wins
to be had, or do we need to think about restructuring the way that we do
builds and/or testing to achieve greater
These stats are *awesome*! I've been wanting them for a long time, but
never got around to generating them myself. Can we track these on an
ongoing basis?
On 11/05/2013 07:09 AM, Ed Morley wrote:
> On 05 November 2013 14:44:27, David Burns wrote:
>> We appear to be doing 1 backout for every 15 pus
Hi David,
On 05/11/2013 16:46, David Rajchenbach-Teller wrote:
Context: I am currently working on patches designed to improve
performance of some subsystems in Firefox Desktop by decreasing disk
I/O, but I hope that they will also have an effect (hopefully
beneficial) on power/battery usage. I'
I am working on using intel power gadget to measure the power usage. Currently
this is on windows with an idle test. Our test slaves have older CPUs which do
not support the intel power gadget.
___
dev-platform mailing list
dev-platform@lists.mozilla.
Good point. Just accessing the battery level is rather imprecise, but
Telemetry + large numbers should help us see trends.
If we go that way, this probably doesn't deserve a new library, but
possibly a few utility functions in e.g. Telemetry or TelemetryStopwatch.
Cheers,
David
On 11/5/13 4:49
If you can access the remaining battery status of a large enough
population over time it should be easy to use telemetry to measure
this pre and post patch.
Andreas
Sent from Mobile.
> On Nov 5, 2013, at 16:46, David Rajchenbach-Teller
> wrote:
>
> Context: I am currently working on patches de
Context: I am currently working on patches designed to improve
performance of some subsystems in Firefox Desktop by decreasing disk
I/O, but I hope that they will also have an effect (hopefully
beneficial) on power/battery usage. I'd like to confirm/infirm that
hypothesis.
Measuring and collecting
using https://treestatus.mozilla.org/mozilla-inbound, I looked at the reasons
for tree closures (usually associated with backouts), going back to 50 status
messages, I found:
38 test issues
14 build issues
9 infrastructure issues
2 other issues
Note, some of these closures had >1 issue documen
A proposal to get this fixed would be immense and ties into the projects
we are doing to help keep engineers productive. Things like parallel
testing[1] should be done to as many test suites as possible, a smoke
test to get feedback loops tighter.
The main one for me is getting easily accessib
On 05/11/13 15:20, Till Schneidereit wrote:
Do we have any way to identify tests that break particularly often for
specific areas? If so, we could create a mach command that runs just these
tests and finishes quickly. Something like `mach canary-tests`.
Isn't the end game for this kind of appr
On 05 November 2013 15:20:06, Till Schneidereit wrote:
Do we have any way to identify tests that break particularly often for
specific areas? If so, we could create a mach command that runs just
these tests and finishes quickly. Something like `mach canary-tests`.
Agree this would be a good way
On Tue, Nov 5, 2013 at 4:09 PM, Ed Morley wrote:
> On 05 November 2013 14:44:27, David Burns wrote:
>
>> We appear to be doing 1 backout for every 15 pushes on a rough
>> average[4].
>>
>
> I've been thinking about this some more - and I believe the ratio is
> probably actually even worse than th
On 05/11/13 14:57, Kyle Huey wrote:
On Tue, Nov 5, 2013 at 10:44 PM, David Burns wrote:
We appear to be doing 1 backout for every 15 pushes on a rough average[4].
This number I am sure you can all agree is far too high especially if we
think about the figures that John O'Duinn suggests[5] for
On 05 November 2013 14:44:27, David Burns wrote:
We appear to be doing 1 backout for every 15 pushes on a rough
average[4].
I've been thinking about this some more - and I believe the ratio is
probably actually even worse than the numbers suggest, since:
* Depending on how the backouts are per
On Tue, Nov 5, 2013 at 10:44 PM, David Burns wrote:
> We appear to be doing 1 backout for every 15 pushes on a rough average[4].
> This number I am sure you can all agree is far too high especially if we
> think about the figures that John O'Duinn suggests[5] for the cost of each
> push for runni
After the major tree closure[1] last week I wanted to see how it
impacted the tree closure stats (stats below in this email) that I have
been watching. I have also been looking to see how many backouts the
sheriffs are doing and seeing how they correlate. For those interested
the tree closure a
On 11/5/13 1:16 AM, Fabrice Desré wrote:
I'm creating a download event with :
let event = new this._window.DownloadEvent("downloadstarted", {
download: createDOMDowloadObject(this._window, data)
});
where createDOMDownloadObject() returns a xpcom object implementing the
webid
I think you want yourPrivateObject.__DOM_IMPL__, which gives you the
binding object as seen by client script.
bholley
On Tue, Nov 5, 2013 at 7:16 AM, Fabrice Desré wrote:
> In the download api we are working on for b2g, a download event in webidl
> looks like:
>
> [Constructor(DOMString type,
2013/11/5 Kyle Huey :
> On Tue, Nov 5, 2013 at 5:50 PM, Sergio López wrote:
> This mailing list stripped your patch, but I gave you editbugs so you can
> comment on the bug now.
OK, thanks!
Sergio.
___
dev-platform mailing list
dev-platform@lists.mozil
Gijs Kruitbosch wrote:
I don't have all my patches applied all the time. If I work on
something, leave it for 2 weeks, and qpush it again, I usually get to
do the "fix all the .rej" dance.
That's an interesting use case. If changeset evolution replaces mq you
could just leave the commit in y
On Tue, Nov 5, 2013 at 5:50 PM, Sergio López wrote:
> Hi,
>
> I tried to attach this patch to bug 78414, but it wasn't possible as
> posting new comments is not allowed.
>
> This proposal is a sensible workaround (as a "complete" solution would
> require the collaboration of every single plugin d
Hi,
I tried to attach this patch to bug 78414, but it wasn't possible as
posting new comments is not allowed.
This proposal is a sensible workaround (as a "complete" solution would
require the collaboration of every single plugin developer, which
doesn't seem feasible) for Windows. Is my understa
33 matches
Mail list logo
