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
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
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 <emor...@mozilla.
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
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
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
/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 emor...@mozilla.com wrote:
tl;dr: Barring any surprises, we would
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
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:
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
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
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
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
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
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
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
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
. 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 OMTC
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
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
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=Tryrev=4ffa00b643cb
The tab title is now:
[0] Description derived from commit message - Try - TBPL
...so that those of you with multiple try push
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
(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
(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:
*
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
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
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
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
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
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
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 periodic
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
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
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
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
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
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
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
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'll
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 when
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
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
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
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
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
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
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
(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
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-management
(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
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
- 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
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
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 run
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
- Original Message -
From: Justin Dolske dol...@mozilla.com
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-changed to use the
intermittent-failure 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,
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
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:
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/~emorley/misc/tbpl-cancel
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
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
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
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
64 matches
Mail list logo
