A few weeks ago in the Tuesday platform call, I said I'd look and see if
I could find any tests in the tree that would capture us changing our
User Agent string. I looked and reviewed many of the tests that do
*something* with the UA string, but I didn't find any that would
actually fail if we
The rate of intermittent failures (which is called the orange factor,
and the effort to diminish it is called The War on Orange) in our
automation has skyrocketed. Starting around February 17 on
mozilla-inbound, we took off on an exponential curve that is making it
extremely hard to sheriff the
On 4/3/2013 4:28 PM, Joshua Cranmer 🐧 wrote:
On 4/3/2013 4:31 PM, Kartikaya Gupta wrote:
For what it's worth, I do recall there being release engineering talk
about some sort of "autoland" feature (which would automatically land
any patch that passed try or something), and I recall (my memory
On 4/3/2013 6:33 PM, jmaher wrote:
I looked at the data used to calculate the offenders, and I found:
total type, total jobs, total duration, total hours
try builders, 3525, 12239477, 3399.8547
try testers, 71821, 121294315, 33692.8652778
inbound builders, 7862, 30877533, 8577.0925
inbound t
On 5/9/2013 10:00 AM, Gregory Szorc wrote:
MozillaBuild was AFAIK the last thing holding us back from requiring
Python 2.7.3 to build the tree. So, I filed bug 870420 to up the build
requirements from 2.7.0+ to 2.7.3+. For the unaware, 2.7.3 fixes a whole
host of small bugs that we constantly ha
Decoder and Jcranmer got code coverage working on Try[1]. They'd like to
expand this into something that runs automatically, generating results
over time so that we can actually know what our code coverage status is
with our major run-on-checkin test harnesses. While both Joduinn and I
are hap
est crashes were one of the big issues with the old system
-- we could never get eyes on the crashes to debug what had happened and
get it fixed.
Thanks,
Clint
On Jun 24, 2013 6:51 PM, "Clint Talbert" <mailto:ctalb...@mozilla.com>> wrote:
Decoder and Jcranmer got code cove
On 7/12/2013 9:49 AM, Gervase Markham wrote:
We keep hitting cases where we would like Firefoxes in the field to have
some data updated using a process which is much lighter in expended
effort than shipping a security release. Here are some examples of the
data Firefox stores that I know of which
Hello all,
I recently proposed a Sheriffing module over in mozilla.governance:
https://groups.google.com/forum/#!topic/mozilla.governance/Knjirdi3suE
The short story is that it's high time we had a module for the Tree
Sheriffs. I propose starting with our current full time sheriffs - Ed
Morl
We have enough tooling in place to see if these affect performance or
not. What we will need is a clear demarcation of when the change is made
to each OS. Ideally the change would go out across all OS's at the same
(or nearly the same) time. If we can at least get the change rolled out
across
Inline
On 6/16/2014 10:23, Sylvestre Ledru wrote:
Hello,
I am working on providing weekly code coverage of Firefox code.
For now, I am able to do that for C/C++ code.
Awesome. Where are you putting these reports? What is the workload used
to generate those reports?
I would like to know if
Hello all,
I know that there is a bunch of confusion in the wake of the recent
reorganization of b2g, so let me set things straight. There is no new QE
department. The QA team is still the same folks, although part of it is in the
B2G org, part of it is in the Services org, and the core QA team
On 9/9/2012 2:03 PM, Justin Lebar wrote:
So, 2.6 or 2.7?
I'm totally in favor of using the latest and greatest that's available.
Me too. I'm in favor of putting all the automation (build & test) on 2.7.3:
https://bugzilla.mozilla.org/show_bug.cgi?id=724191
Clint
On 9/26/2012 8:32 AM, Armen Zambrano G. wrote:
On 12-09-26 6:45 AM, Neil wrote:
Perhaps the file system permissions are incorrect and NT
AUTHORITY\NETWORK SERVICE doesn't have permission to access
C:\WINDOWS\system32\wbem\wmiprvse.exe ?
You might be right.
How can I check this? I'm not very f
On 9/27/2012 6:52 AM, Armen Zambrano G. wrote:
On 12-09-27 7:03 AM, Neil wrote:
I'd suggest read & execute rather than full access ;-) Also, you might
find you actually need to grant permission on a containing folder.
Yeah you wouldn't want to leave it that way, but granting full access to
i
We are in the process of adding PandaBoards [1] to the Fennec test pool.
That means that simply stating "Android opt" on TBPL won't really enable
us to distinguish between the Tegra Boards (android 2.2) and the
PandaBoards (android 4.0).
So, I propose we add the versions to the row names for t
I'm not sure what you mean because as best I understand it, the Selenium
Firefox driver is an extension and thus runs in the same process space
as Firefox itself. If you're looking for a closer binding between your
automation code and Firefox, you can take a look at our new automation
mechanis
On 12/1/2012 2:29 PM, Gregory Szorc wrote:
The bump to Python 2.6 seemed to go OK. So, I think it's time to finish
the transition and bump the minimum to Python 2.7.
Per the previous discussion on this list, I don't believe we have any
outstanding objections. So, I propose we move forward with t
I agree in part with the assertion about testing - that the existing
reftests will catch most regressions stemming from this. But I think we
also need some measurements around scrolling/responsiveness in order to
verify that off main thread painting is giving us the wins we hope it
will give us
19 matches
Mail list logo
