OrangeFactor now behind LDAP auth

OrangeFactor [1] is 6 years old, unowned and has remained mostly unchanged in recent years. Whilst it is due to be replaced by a Treeherder API based solution in the next few quarters [2], we have had to put it behind LDAP authentication in the meantime as a defence in depth protection against the

Retaining Nightly users after disabling of legacy extensions

Some context: - As part of Firefox 57 no longer supporting legacy (non web extension) add-ons, the `extensions.legacy.enabled` preference was flipped to false in the Aug 11th Nightly build [1]. - Several backwards incompatible changes have already been made to Nightly that can break legacy extensio

Changes to automated bug comments for intermittent failures

Currently whenever a sheriff or developer classifies an intermittent failure on Treeherder with a bug number, a comment is left on that bug for every occurrence. We're going to be turning these comments off, and replacing them with periodic summaries of recent failures, in order to: * Improve the

Treeherder maintenance today approx 0530-0600 PDT

In order to migrate Treeherder from SCL3 to Heroku, for approx 30 minutes from 0530 PDT today: * Treeherder's API will be read-only * The ingestion of push/job data will be paused Whilst the trees are normally quiet at this time of day, to prevent a build-up of pushes without visible results causi

Re: Treeherder maintenance today approx 0530-0600 PDT

Treeherder has now successfully been migrated to Heroku. Trees were closed for 25 minutes (other than try, which remained open throughout). For timeline, see: https://bugzilla.mozilla.org/show_bug.cgi?id=1307741#c3 Best wishes, Ed On 5 October 2016 at 12:35, Ed Morley wrote: > In order

Re: proposal: replace talos with inline tests

(CCing auto-to...@mozilla.com) jmaher and jhammel will be able to comment more on the talos specifics, but few thoughts off the top of my head: It seems like we're conflating multiple issues here: 1) "[talos] is a separate repo from mc" 2) "[it's a hassle to] test the test to be sure it’s wo

Re: The War on Orange Needs YOU

Just to follow up on this - yesterday the metrics Elastic Search cluster experienced some data loss, with OrangeFactor being amongst the services affected. It's not yet clear if there is a backup available [1][2], so for now the stats shown on http://brasstacks.mozilla.com/orangefactor/ are mi

TBPL job visibility policy - now documented

(Please reply to dev.tree-management) Until now, the requirements for a new platform/test-suite to be shown in the default TBPL view have been scattered across many newsgroup discussions, bugs & IRC conversations, which understandably leads to surprise when developers working on bringing a new

Re: TBPL job visibility policy - now documented

I've replied to the last few posts on dev.tree-management :-) https://lists.mozilla.org/listinfo/dev-tree-management https://groups.google.com/d/topic/mozilla.dev.tree-management/N8xmYtgVp74/discussion On 3/26/2013 7:10 AM, Ed Morley wrote: (Please reply to dev.tree-manag

Re: End of life for tinderbox.mozilla.org

On 03 April 2013 15:21:33, Neil wrote: Since tinderboxpushlog no longer uses tinderbox, maybe it should get renamed ;-) Agreed - TBPL's successor is going to be called something other than TBPL2 (name chosen so far is treeherder). Best wishes, Ed

Re: Landing on Trunk - Target Milestone vs. Status Flag Usage vs. Tracking for Future Releases

On 11/04/2013 03:32, Jason Smith wrote: That's a good idea. Should we file a bug to do this? On 4/10/2013 5:14 PM, Gregory Szorc wrote: why don't we have a checkin hook or bot automatically update Bugzilla flags when changesets are pushed? Agree would be good - bug 805874 was filed for this :

Re: Automatic tree clobbering is coming

On 17/04/2013 20:51, Ms2ger wrote: On 04/17/2013 09:36 PM, Gregory Szorc wrote: It /could/, sure. However, I consider auto clobbering a core build system feature (sheriffs were very vocal about wanting it). As such, it needs to be part of client.mk. (Please correct me if I am wrong.) This shou

Re: Some data on mozilla-inbound

On 23 April 2013 09:58:41, Neil wrote: Hopefully a push never burns all platforms because the developer tried it locally first, but stranger things have happened! This actually happens quite often. On occasion it's due to warnings as errors (switched off by default on local machines due to too

Re: Some data on mozilla-inbound

On 23/04/2013 17:28, Kartikaya Gupta wrote: On 13-04-23 00:39 , Ehsan Akhgari wrote: How hard would it be to gather a list of the total number of patches being backed out plus the amount of time that we spent building/testing those, hopefully in a style similar to

Re: Automatic tree clobbering is coming

On 23 April 2013 19:59:28, Chris Lord wrote: Having just read up the replies, it seems that it's generally agreed that this would be better as an opt-in feature. Is anyone tasked to make it such? Is there a bug I can follow for it? Bug 863091 (I've attached a patch, which will land soon). Ed _

Re: Improving Mac OS X 10.6 test wait times by reducing 10.7 load

On 25 April 2013 20:14:10, Justin Lebar wrote: Is this what you're saying? * 10.6 opt tests - per-checkin (no change) * 10.6 debug tests- reduced * 10.7 opt tests - reduced * 10.7 debug tests - reduced * reduced --> m-c, m-a, m-b, m-r, esr17 Yes. Now that I think about

Automated builds/tests can no longer rely on external resources (aka RelEng firewall now set to Deny-All)

It has been our policy [1] to discourage builds/tests run in automation from relying on resources outside of the build network, to avoid non-deterministic failures across the board and to reduce noise in performance tests. As of Saturday, this policy will be enforced by the RelEng firewall be

Re: Automated builds/tests can no longer rely on external resources (aka RelEng firewall now set to Deny-All)

On 11 July 2013 21:49:02, Neil wrote: As of Saturday, this policy will be enforced by the RelEng firewall being set to Deny-All by default Is it not possible to modify the .pac file used by tests to stop them accessing any network resources? (Or at least only those that have had to be whitelist

Re: Rethinking build defaults

On 16/08/2013 15:14, Adam Roach wrote: What I'm worried about, if we start disabling various modules, is that we're going to have regressions that go unnoticed on developer systems, blow up on m-i, and then take a _long_ time to track down. They shouldn't take a long time to track down - a simp

Updates to bzexport & qimportbz

tl;dr: Please update your local bzexport & qimportbz clones :-) bzexport & qimportbz (Mercurial extensions to allow direct patch import/export from/to Bugzilla [1][2]) have received a number of new features/fixes over the last 12 months, including... bzexport: * Setting assignee/bug state whe

Re: Getting the current release version

On 30 August 2013 15:09:08, Eric Shepherd wrote: This could even be a place in the source code we could pull up a MXR link and peel out of the code. I just don't know where in the code to get it. For platform: https://hg.mozilla.org/releases/mozilla-release/file/tip/config/milestone.txt For Fi

Re: Getting the current release version

On 30 August 2013 15:14:54, Ed Morley wrote: For platform: https://hg.mozilla.org/releases/mozilla-release/file/tip/config/milestone.txt For Firefox (and yeah currently the same as platform): https://hg.mozilla.org/releases/mozilla-release/file/tip/browser/config/version.txt (Although you&#x

Minimal tree sheriff coverage from now until Tues 8th EST

Hi all Due to the summit & travel before/after, there will be minimal sheriff coverage from roughly now, until start of day Eastern Time on Tuesday 8th at the earliest. The trees will remain open for now - and the sheriffs will possibly be able to look at them a couple of times between now a

Re: Master Password (was Re: What platform features can we kill?)

On 10 October 2013 10:22:13, Michael Lefevre wrote: I wouldn't disagree with any of the other reasons, but could you clarify what you mean when you say the cryptography is useless? FireMaster seems to just brute force passwords. Are you just saying that any cryptography that relies on a password

Re: Cost of ICU data

On 16 October 2013 23:10:39, Gregory Szorc wrote: Possible crazy idea: do we actively track and send tree management notices when package or binary size changes? Not at present as far as I know, though Tim Taubert created something temporary last year (no longer accessible, but perhaps worth f

Closure of trunk trees - owners for bugs needed

anyone who has any spare cycles take a look! :-) Best wishes, Ed [1] Apart from b2g-inbound, since that doesn't run Windows 7 tests, which are the ones that are being the most problematic. On 30 October 2013 14:09:47, Ed Morley wrote: I've broken the tree closing issues out

Tree sheriffs - email/bugzilla alias & etherpad for sheriffing current issues

Hi all! * The tree sheriffs [1] now have a Bugzilla alias that you can use to make us aware of any potential tree issues. To use, please CC: sheri...@mozilla.bugs * We also have a sheriffing team email alias: sheriffs at mozilla.org (Note: .org rather than .com) * In order to facilita

Re: Closure of trunk trees - owners for bugs needed

On 01/11/2013 01:58, Nicholas Nethercote wrote: One more: lots of patches will need to be backported to Aurora and Beta. I've set the appropriate tracking flags on the bugs that I think need it, but please double-check ones you know about in case I've missed any. Nick I'll keep an eye on the

Re: Pushes to Backouts on Mozilla Inbound

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

Re: Pushes to Backouts on Mozilla Inbound

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

Re: How to reduce the time m-i is closed?

On 16/11/2013 15:17, smaug wrote: the recent OOM cases have been really annoying. They have slowed down development, even for those who haven't been dealing with the actual issue(s). Could we handle this kind of cases differently. Perhaps clone the bad state of m-i to some other repository we're

Re: Test errors

On 19 November 2013 17:16:16, Neil wrote: So I was quite surprised to find all manner of junk seems to get reported to the console in a typical test run, including such goodies as "ReferenceError: is is not defined". Why does that not seem to cause a problem yet one particular exception causes a

Re: Unified builds

On 21 November 2013 15:38:28, Ehsan Akhgari wrote: We don't, we clobber periodically. I'm not sure why that is better than never clobbering... We've been force-clobbering 1-2 times a day in automation for several months now sadly, due to bug 928195 and similar prior. (Patches almost ready to

Re: Unified builds (regarding periodic clobber)

> On 11/21/13, 8:40 AM, Ehsan Akhgari wrote: >> Yes, but our periodic clobber has been in effect long before that bug >> (and in fact for as long as I can remember.) Yes, but it's only once a week rather than a couple of times a day :-) On 21/11/2013 16:45, Gregory Szorc wrote: Do we need perio

Documenting common patterns that cause intermittent test failures

Hi! If you've recently fixed an intermittent test failure - please can you see if the cause was something that should be documented on the best practices guide: https://developer.mozilla.org/en-US/docs/Mozilla/QA/Avoiding_intermittent_oranges The page was last added to in 2011 - I'm keen to

Workaround for hg.mozilla.org timeouts with TBPL try results

TBPL try pushes have recently been failing to load, due to problems with the try pushlog on hg.mozilla.org (bug 959769). In the last few days I have landed a workaround in TBPL (bug 721152) that means you can continue to see your job results for a single push, even if the hg.mozilla.org pushlog

Re: Workaround for hg.mozilla.org timeouts with TBPL try results

On 19 January 2014 16:35:11, Ed Morley wrote: In addition, this change will mean that try repository resets (done periodically to avoid problems with the way we abuse mercurial for try server) will no longer stop you accessing old job results - as long as you have the revision URL from the

Re: Consensus sought - when to reset try repository?

On 05 March 2014 06:07:28, Gregory Szorc wrote: I wouldn't have such a big issue with Try resets if we didn't lose information in the process. I believe every time there's been a Try reset, I've lost data from a recent (<1 week) Try push and I needed to re-run that job Whilst it doesn't help wi

Re: Policy for disabling tests which run on TBPL

On 06 April 2014 14:58:24, Ehsan Akhgari wrote: On 2014-04-06, 8:59 AM, Aryeh Gregor wrote: Is there any reason in principle that we couldn't have the test runner automatically rerun tests with known intermittent failures a few times, and let the test pass if it passes a few times in a row after

Formalising the current 'mozilla-central essential pushes only' recommendation

(Follow-ups to dev.tree-management please) Hi all :-) The vast majority of mozilla-central landings are now via curated merges from integration/team repositories. This dramatically increases the chance that the tip of mozilla-central is in a known-good state, meaning that: * Integration/pro

Re: [Sheriffs] UPDATE: Current action plan for try server issues

Please could we look into updating hg.mozilla.org to a newer Mercurial as well? (a la bug 945383) It seems that many of the suggestions made across the various try issues threads are dependant on newer Hg - and the perf improvements in newer releases alone will help :-) Many thanks for your he

Re: Update on sheriff-assisted checkin-needed bugs

Autoland should solve that use case :-) https://bugzilla.mozilla.org/show_bug.cgi?id=657828 On 19 May 2014 22:01:25, Jonas Sicking wrote: Try-from-bugzilla would be awesome! / Jonas On Mon, May 19, 2014 at 1:53 PM, Bobby Holley wrote: (Reducing the thread scope for the followup) One issue I

Re: Formalising the current 'mozilla-central essential pushes only' recommendation

On 07/04/2014 10:37, Ed Morley wrote: Non-critical mozilla-central landings are already discouraged and as such are rare. However, the sheriffs [2] would like to formalise this, by adjusting the mozilla-central tree rules [3] to state that direct pushes must be for one of the following reasons

********: MXR now displays links to Github log & blame for Gaia/Rust/Servo

MXR now links to the Github log & blame pages from the view single file and free-text search result pages for the Gaia, Rust and Servo repositories (bug 1024443). This means that for cases where Github code search is inadequate (eg: filename search via bookmark keyword or custom search engine

Re: ********: MXR now displays links to Github log & blame for Gaia/Rust/Servo

(Sorry about the subject prefix, that wasn't there prior to sending; time to debug the Thunderbird addons :-/) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Identifiable TBPL Try push tab titles

Bug 1020919 has been pushed to production, meaning that for TBPL pages displaying just a single Try-server push - eg: https://tbpl.mozilla.org/?tree=Try&rev=4ffa00b643cb The tab title is now: "[0] Description derived from commit message - Try - TBPL" ...so that those of you with multiple try pu

Re: Test failures in mochitest-browser caused by doing work inside DOM event handlers

On 25/06/2014 15:16:04, Chris Mills wrote: It looks like a good place to put this information would be as a subsection of https://developer.mozilla.org/en/docs/Mochitest#Writing_tests Can you add in a brief section covering this point, along with a brief code snippet illustrating a good and a b

Re: Misunderstood the "Assigned" at bugs! Sorry !!!

On 09/07/2014 16:48:05, Gijs Kruitbosch wrote: As glob noted upthread, the NEW/ASSIGNED distinction is sometimes used by people when they are the assignee. There is only a lack of difference when the assignee is "nob...@mozilla.org". That doesn't warrant abolishing the status (although we could a

Re: Linux Off-main-thread compositing (OMTC) enabled

On 21/07/2014 16:53:37, Christopher Lord wrote: Earlier today, I pushed the patch that enables OMTC on Linux[1][2], meaning we will now have OMTC enabled on all platforms. Linux is slightly different to other platforms, as we currently have hardware-accelerated layers disabled. This means it u

Re: Linux Off-main-thread compositing (OMTC) enabled

. It happens to me, and to a couple of people on twitter. How do I disable OMTC from the command line to see if it's OMTC related? Ed Morley wrote: On 21/07/2014 16:53:37, Christopher Lord wrote: Earlier today, I pushed the patch that enables OMTC on Linux[1][2], meaning we will now have

Re: Intent to Transition from TBPL to Treeherder

On 23/07/2014 08:04, Boris Zbarsky wrote: 1) It's trying to run Flash. Will it work correctly if I just don't let it do that? I haven't found anything broken so far even though I didn't allow the Flash. Bug 1030710 removed the "copy to clipboard" use of flash - the only other use is as a so

Re: Intent to Transition from TBPL to Treeherder

On 25/07/2014 04:37, Nicholas Nethercote wrote: One comment: the visual distinction between a dark grey (running) and green (successful) job is much less than on TBPL. Could a very light green background and darker green border be used, similar to the orange and red boxes, to make the green jobs

Re: Intent to Transition from TBPL to Treeherder

On 25/07/2014 05:20, Mike Hommey wrote: On Fri, Jul 25, 2014 at 12:04:30AM -0400, Ehsan Akhgari wrote: I would like to help dogfood this, and want to know if I can trust the data parity of Treeherder and TBPL, or if that is something that you would like testing on? IOW, should I keep them both

Re: Intent to Transition from TBPL to Treeherder

On 30/07/2014 18:22:39, Botond Ballo wrote: I seem to have to refresh Treeherder to get it to update job statuses, whereas on TBPL the statuses update automatically. Is this expected? This isn't expected, have filed: https://bugzilla.mozilla.org/show_bug.cgi?id=1046642 Cheers, Ed ___

Re: Help for new MDN page on testing frameworks (technical and editorial)

On 13/08/2014 16:40, Paolo Amadini wrote: I've just updated the MDN page about the testing frameworks to add more details, like the process where the tests run in an e10s build, and moved everything to a table to make the information more accessible. Thank you for doing that! :-) (Also CCing aut

Re: Disabling a few mochitests this week, and upcoming changes next week to browser-chrome

On 19/08/2014 16:46, Gavin Sharp wrote: A few issues here: - This particular case (we're making broad changes to how the tests run that causes many new failures) was not what that policy was meant to cover. We need some leeway to handle this situation differently. Agreed that this case is possi

Re: Experiment with running debug tests less often on mozilla-inbound the week of August 25

On 19/08/2014 21:55, Benoit Girard wrote: I completely agree with Jeff Gilbert on this one. I think we should try to coalesce -better-. I just checked the current state of mozilla-inbound and it doesn't feel any of the current patch really need their own set of tests because they're are not time

Re: Experiment with running debug tests less often on mozilla-inbound the week of August 25

I think much of the pushback in this thread is due to a misunderstanding of some combination of: * our current buildbot scheduling * the proposal * how trees are sheriffed and merged To clarify: 1) We already have coalescing [*] of jobs on all trees apart from try. 2) This coalescing means tha

Sheriffs have transitioned from TBPL to Treeherder

Hi! (Replies to dev.tree-management please) The A-Team's Treeherder project [1] has completed its next milestone: The sheriff team [2] is now using it to monitor repository code health instead of TBPL [3]. A massive thanks to all of the developers [4] who have worked hard [5] to get us to t

Re: Documenting uses of Github at Mozilla

Perhaps part of the solution is to move at least some of the other repositories to the main Mozilla Github org (along with a rethink of the groups naming/structure to keep permissions sane) rather than have many top level "organisations"? eg all repos under orgs like: https://github.com/mozilla

Re: treating B2G device tests as tier 1

On 15/10/2014 22:15, Trevor Saunders wrote: However I think that was a mistake, it treated those tests as tier 1 when they pretty clearly do not meet the requirements in https://wiki.mozilla.org/Sheriffing/Job_Visibility_Policy ... The visibility rules exist in part to make sure that tier 1 tes

Switching TBPL off at the end of the month

tl;dr: Barring any surprises, we would like to switch off TBPL [1] at the end of the month. == Treeherder (TBPL's replacement)[2] has been in production since the summer, and used as the primary tree-management tool by sheriffs since September. Since then, the majority of users of TBPL have switc

TBPL now redirects to Treeherder

bpl/rev/73ad7a52c30e [2] https://wiki.mozilla.org/Auto-tools/Projects/Treeherder [3] https://treeherder-ui.readthedocs.org/en/latest/installation.html [4] https://lists.mozilla.org/listinfo/dev-tree-management On 9 March 2015 at 03:52, Ed Morley wrote: > tl;dr: Barring any surprises, we would like

Treeherder UI performance much worse in Nightly vs Chrome

Scrolling fluidity/general app responsiveness of Treeherder is massively worse in Nightly compared to Chrome. eg try this in both: https://treeherder.mozilla.org/#/jobs?repo=mozilla-central The problem is even more noticeable when the "get next 50" buttons is pressed at the bottom of the page. I

FileIt has moved

FileIt (a tool for quickly finding the product/component for filing a bug) has been moved from Heather's github account to mine, since she no longer wishes to maintain it. It can now be found here: https://edmorley.github.io/fileit/ (Unfortunately Github doesn't set up HTTP redirects for a transf

Try Server wait times - please cancel unwanted/busted runs

Hi! As many of you are no doubt aware, Try Server load has been very high recently [1] (sometimes taking up to 24 hours to get a full set of results). Bug 772458 has some dependants that will help, but won't make a significant difference in the short term. In the meantime please can everyone

Using TryChooser -p macosx? Use macosx64 instead...

Until recently, using TryChooser with -p macosx would give you working OS X 10.5 builds & test runs. However, now that the OS X requirement on trunk has been raised to 10.6 [1], any Try runs based on trunk need to use -p macosx64 (ie 10.6/10.7) rather than -p macosx or your test runs will be:

Re: Using TryChooser -p macosx? Use macosx64 instead...

On Thursday, 19 July 2012 23:28:39 UTC+1, Ed Morley wrote: > However, now that the OS X requirement on trunk has been raised to 10.6 [1] [1] https://bugzilla.mozilla.org/show_bug.cgi?id=772682 ___ dev-platform mailing list dev-platf

Re: Using TryChooser -p macosx? Use macosx64 instead...

On Friday, 20 July 2012 13:19:26 UTC+1, Rafael Ávila de Espíndola wrote: > So we are not running any 32 bit tests anymore? I don't believe so. > Should we reuse 'macox' > to run the 32 bit debug build on a 10.6 machine? I'll leave the decision of whether they are still useful to someone else;

Re: Using TryChooser -p macosx? Use macosx64 instead...

On Friday, 20 July 2012 19:44:54 UTC+1, Dave Townsend wrote: > Can we update http://trychooser.pub.build.mozilla.org/ to not offer > macosx, or to highlight that it is broken? The page does already state they are for 10.5 builds, but I've filed a bug to get it changed to mention broken/EOL on t

Re: Disabling tests

On Friday, 3 August 2012 02:30:03 UTC+1, Philip Chee wrote: > If it's random, how do you know if you've actually fixed it without > having to waste your time watching the tree for a week? http://brasstacks.mozilla.com/orangefactor/ ___ dev-platform mail

Increase in mozilla-inbound bustage due to people not using Try

Increasingly over the last few weeks, people have been landing untested changes on mozilla-inbound that has resulted in bustage - which with high levels of coalescing (that makes finding the culprit require multiple time-consuming re-triggers) has meant closing the tree for several hours. For

Re: Increase in mozilla-inbound bustage due to people not using Try

On Thursday, 9 August 2012 15:35:28 UTC+1, Justin Lebar wrote: > Is there a plan to mitigate the coalescing on m-i? It seems like that > is a big part of the problem. Reducing the amount of coalescing permitted would just mean we end up with a backlog of pending tests on the repo tip - which wo

Re: Treestatus replacing tinderbox for tree closure - if you need access but don't yet have it, please let me know!

On Friday, 8 June 2012 19:02:30 UTC+1, Ed Morley wrote: > Treestatus (http://treestatus.mozilla.org) will soon be replacing Tinderbox > as the means to open/close and set status messages for all mozilla-* trees, > as well as the Thunderbird parts of the comm-* trees [1]. catlee++ :-D

Re: The current state of Talos benchmarks

Thank you for posting this - I've become increasingly worried by the number of real regressions that we are likely missing due to the current situation. Like yourself I used to read every single dev.tree-management mail & try to act on those that looked real, however after many months of not fee

TBPL updates

Over the last month or so a number of updates have been rolled out to TBPL [1]. The user-facing highlights are: * MOZ_ASSERT failures are now recognised by the TBPL log parser & so are displayed in the failure summary box alongside bug suggestions. * Clicking on the jobname (in the left-hand pane

Switching oranges to use keyword 'intermittent-failure', rather than whiteboard '[orange]'

For every failure on TBPL, at least one (and often several) BZAPI call(s) is/are performed in order to generate the list of suggested bugs. However at present, we file intermittent failures with [orange] in the whiteboard, which is much less performant when searching, compared to using a keyword

Re: Try Server wait times - please cancel unwanted/busted runs

On Thursday, 19 July 2012 13:56:22 UTC+1, Ed Morley wrote: > In the meantime please can everyone remember to cancel unwanted/busted Try > runs, to help the overall wait time. > > Builds/tests can be cancelled all at once, or on a per job basis: > http://people.mozilla.com/~em

mochitest-browser-chrome now split out from mochitest-other - adjust your trychooser syntax

At the end of last week, mochitest-browser-chrome was split out from mochitest-other (bug 791389), roughly halving the time taken for mochitest-other to complete. Trychooser [1] has been updated, but if you either type from memory or use saved MQs, please use 'mochitest-bc' if mochitest-browser

Testing single platforms on Try? Use Linux64 instead of Linux32 for fastest turnaround

Whilst Linux32 is on average our fastest building platform (by ~5-10 mins over Linux64), it currently has much longer test wait times [1] (time until a testpool machine is available to take the job). For example there are currently over 1000 queued Linux32 test jobs on Try, but only 26 for Lin

Re: Testing single platforms on Try? Use Linux64 instead of Linux32 for fastest turnaround

On Thursday, 6 December 2012 18:08:23 UTC, Ehsan Akhgari wrote: > Doesn't this trend just get reversed if everyone starts to use Linux64 now? > > Ehsan No, the B2G emulator tests will still be using the Linux32 slaves & are the primary cause of the problem at the moment. At such point if/when w

Re: Testing single platforms on Try? Use Linux64 instead of Linux32 for fastest turnaround

On Thursday, 6 December 2012 18:18:53 UTC, Andrew McCreight wrote: > Is there any possibility of getting a '-p whatever' that would > semi-intelligently pick a desktop platform that isn't overwhelmed with > build/test jobs? For the kinds of bugs I work on, I don't really care which > one it ru

Re: Try Server wait times - please cancel unwanted/busted runs

On Thursday, 27 September 2012 14:30:01 UTC+1, Ed Morley wrote: > > In the meantime please can everyone remember to cancel unwanted/busted Try > > runs, to help the overall wait time. > > > > Builds/tests can be cancelled all at once, or on a per job basis: >

TBPL repo move

Hi all In the last week, bug 772546 moved TBPL [1] development from a user repo, to: https://hg.mozilla.org/webtools/tbpl/ ...in order to make it more discoverable. As before, if you have any TBPL requests/suggestions, please file them at: https://bugzilla.mozilla.org/enter_bug.cgi?product=Webtoo

Filing bugs for intermittent failures on TBPL - new keyword

Hi all Bugs filed for intermittent failures (aka "random oranges") seen on our test automation have now been transitioned to using a new bugzilla keyword instead of the whiteboard annotation. This helps to reduce the load on bugzilla caused by TBPL's BzAPI calls, when it searches for bugs to su

Re: Filing bugs for intermittent failures on TBPL - new keyword

- Original Message - > From: "Justin Dolske" > > On 12/20/12 7:54 AM, Ed Morley wrote: > > The whiteboard annotation "[orange]" and meta bug dependency should > > no longer be set. > > Will existing bugs with said annotation be mass-chan

Re: Filing bugs for intermittent failures on TBPL - new keyword

- Original Message - > Yup, the mass change from whiteboard to keyword happened in the last > week of November in bug 814083, thanks to dkl, glob and fox2mike :-) I should add that this was done via a direct DB change to avoid bugspam whilst changing the ~4000 intermittent-failure bugs, w

Re: Proposal to change the semantics of DONTBUILD

On 15/01/2013 23:52, Daniel Holbert wrote: In that scenario (if it exists) you could always use the build API (and the shortcut red-stopsign buttons on TBPL) to effectively get what you want. Killing running builds would mean needing to clobber all machines for all platforms for that tree (unt

Re: The state of the Aurora branch

On 17 January 2013 22:58:20, Ehsan Akhgari wrote: > The Aurora tree was closed yesterday by Ed because of the perma-orange > failure filed in bug 823989, which went unnoticed for quite some time Both the failure fixed by Ehsan & the remaining ones on aurora are Nightly-only. Unfortunately tests r

Re: The state of the Aurora branch

On 19 January 2013 15:01:09, Ehsan Akhgari wrote: > dbaron posted a summary of our options on release-drivers Please can that be posted somewhere public for those of us not on release-drivers? Cheers, Ed (Away until Monday 21st Jan) ___ dev-platform m

Re: The future of PGO on Windows

- Original Message - > We should also remind that there would be an infra load win from > disabling Windows PGO builds. Plus less of a lead time waiting for PGO results before an inbound -> mozilla-central merge can be performed :-D (even if we keep PGO on other platforms, Windows was alw

Re: Increase in memory utilization on Mac OSX 10.7+ due to history swipe animations

On 12 February 2013 22:11:12, Stephen Pohl wrote: I wanted to give a heads up that we're in the process of finalizing the patch for bug 678392 which will give us history swipe animations on Mac OSX 10.7+. Since we will be taking snapshots of the 20 most-recently visited pages, this will undoubted