Re: PSA: Python min version bumped to 3.6 for building gecko

The pyenv[1] project is a great way to manage multiple versions of python on your system. I've found it easier than trying to compile directly from source. Cheers, Chris [1] https://github.com/pyenv/pyenv On Wed, 10 Jun 2020 at 16:52, Kartikaya Gupta wrote: > For those of you who like me are

Re: Proposal to adjust testing to run on PGO builds only and not test on OPT builds

Thank you Joel for writing up this proposal! Are you also proposing that we stop the linux64-opt and win64-opt builds as well, except for leaving them as an available option on try? If we're not testing them on integration or release branches, there doesn't seem to be much purpose in doing the

Re: Launch of Phabricator and Lando for mozilla-central

This is really great news, I'm really excited to start using it! Automated landings from code review is such a game changer for productivity and security. Congrats to everyone involved. Cheers, Chris On Wed, 6 Jun 2018 at 11:01, Mark Côté wrote: > > The Engineering Workflow team is happy to

Re: Removing tinderbox-builds from archive.mozilla.org

On Tue, 29 May 2018 at 14:21, L. David Baron wrote: > > On Monday 2018-05-28 15:52 -0400, Chris AtLee wrote: > > Here's a bit of a strawman proposal...What if we keep the > > {mozilla-central,mozilla-inbound,autoland}-{linux,linux64,macosx64,win32,win64}{,-pgo}/ > >

Re: Removing tinderbox-builds from archive.mozilla.org

On Sun, 20 May 2018 at 19:40, Karl Tomlinson wrote: > On Fri, 18 May 2018 13:13:04 -0400, Chris AtLee wrote: > > IMO, it's not reasonable to keep CI builds around forever, so the question > > is then how long to keep them? 1 year doesn't quite cover a full ESR cycle, >

Re: Removing tinderbox-builds from archive.mozilla.org

The discussion about what to do about these particular buildbot builds has naturally shifted into a discussion about what kind of retention policy is appropriate for CI builds. I believe that right now we keep all CI build artifacts for 1 year. Nightly and release builds are kept forever. There's

“approval required” for changes affecting CI infrastructure

To ensure a successful Firefox 57 release, teams responsible for Firefox CI & release infrastructure have adopted an “approval required” policy for changes that could impact Firefox development or release. This includes systems like buildbot, Taskcluster services, puppet, hg, product delivery, and

Firefox Nightly - now with twice as many builds a day!

Bug 1349227[1] landed a few days ago, which means we are now doing "nightly" builds twice a day at 1000 and 2200 UTC. The purpose of doing multiple nightlies is to get fixes out to users in Europe, Africa and Asia sooner. We have some concerns about possible impact to the build infrastructure,

Re: Nightly updates disabled for bug 1364059

Updates are enabled again for all platforms. Not all locales have finished yet, they will receive updates once the repacks finish. On 11 May 2017 at 09:30, Chris AtLee <cat...@mozilla.com> wrote: > We've disabled updates for a bad crash: https://bugzilla.mozilla.org/ > show_bug.cg

Nightly updates disabled for bug 1364059

We've disabled updates for a bad crash: https://bugzilla.mozilla.org/show_bug.cgi?id=1364059 We're working on backing out the offending patches and will re-spin nightly builds shortly. Cheers, Chris ___ dev-platform mailing list

Reminder - TCW tomorrow May 6th from 0500-1200 PT

As indicated on our status page: https://status.mozilla.org/incidents/cpnkqqb6b5kh We will be closing trees tomorrow from 0500-1200PT. Tracking bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1355897 Thank you for your patience ___ dev-platform

Re: Reproducible builds

Regarding timestamps in tarballs, using tar's --mtime option to force timestamps to MOZ_BUILD_DATE (or a derivative thereof) could work. On 19 July 2016 at 04:11, Kurt Roeckx wrote: > On 2016-07-18 20:56, Gregory Szorc wrote: > >> >> Then of course there is build signing, which

Win8 tests disabled by default on Try

We've been having a lot of problems with capacity for our Windows test pools, with Windows 8 being particularly bad. Today we disabled running Windows 8 64-bit tests by default on Try. If you do really need Windows 8 tests for your try pushes, you can add try syntax like this to enable: "try: -b

Windows 7 tests in AWS

I'm very happy to let you know that we've recently started running some of our Windows 7 tests in AWS. Currently we're running these suites in Amazon for all branches of gecko 49 and higher: * Web platform tests + reftests * gtest * cppunit * jittest * jsreftest * crashtest Since these are now

Re: To bump mochitest's timeout from 45 seconds to 90 seconds

On 9 February 2016 at 14:51, Marco Bonardo wrote: > On Tue, Feb 9, 2016 at 6:54 PM, Ryan VanderMeulen > wrote: > > > I'd have a much easier time accepting that argument if my experience > > didn't tell me that nearly every single "Test took longer than

Re: Using the Taskcluster index to find builds

In this case, latest is just latest from wherever. I agree that l10n nightlies should be under 'nightly' as well. On Wed, Dec 2, 2015 at 3:04 PM, Axel Hecht <l...@mozilla.com> wrote: > On 12/1/15 3:48 PM, Chris AtLee wrote: > >> Localized builds should be at e.g. &

Faster Windows builds everywhere!

A few weeks ago I posted about switching our Windows builds on Try over to EC2, resulting in a 30 minute speed improvement. Last week we made the same change to the rest of the Windows build infrastructure. All our Windows builds are now running in AWS. We're seeing good performance gains there

Re: Faster Windows builds everywhere!

, Justin Dolske <dol...@mozilla.com> wrote: > On 12/1/15 12:41 PM, Chris AtLee wrote: > > Last week we made the same change to the rest of the Windows build >> infrastructure. All our Windows builds are now running in AWS. We're >> seeing >> good performance ga

Re: Faster Windows builds everywhere!

On Tue, Dec 1, 2015 at 5:27 PM, Gregory Szorc <g...@mozilla.com> wrote: > > On Tue, Dec 1, 2015 at 2:21 PM, Chris AtLee <cat...@mozilla.com> wrote: > >> Right now we've got debug OSX builds in the cloud on Try in parallel with >> the regular builds. The

Re: Using the Taskcluster index to find builds

we can have both. But > before filing a bug, I'd like to know if the general population thinks > it's a good idea. > > -- > Julien > > Le 30/11/2015 21:43, Chris AtLee a écrit : > > The RelEng, Cloud Services and Taskcluster teams have been doing a lot of > > work b

Re: Using the Taskcluster index to find builds

ed builds and their assets by glancing at things. > Are those to come? > > Also, I suspect we should rewrite wget-en-US? Or add an alternative that's > index-bound? > > Axel > > On 11/30/15 9:43 PM, Chris AtLee wrote: > >> The RelEng, Cloud Services and Taskclus

Re: Using the Taskcluster index to find builds

The expiration is currently set to one year, but we can (and should!) change that for nightlies. That work is being tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=1145300 On Mon, Nov 30, 2015 at 7:00 PM, Ryan VanderMeulen <rya...@gmail.com> wrote: > On 11/30/2015 3:43 PM, Ch

Re: Using the Taskcluster index to find builds

are critical for regression hunting. > > On 12/1/2015 9:49 AM, Chris AtLee wrote: > >> The expiration is currently set to one year, but we can (and should!) >> change that for nightlies. That work is being tracked in >> https://bugzilla.mozilla.org/show_bug.cgi?id=1145300 &g

Using the Taskcluster index to find builds

The RelEng, Cloud Services and Taskcluster teams have been doing a lot of work behind the scenes over the past few months to migrate the backend storage for builds from the old "FTP" host to S3. While we've tried to make this as seamless as possible, the new system is not a 100% drop-in

Faster Windows builds on Try

Over the past months we've been working on migrating our Windows builds from the legacy hardware machines into Amazon. I'm very happy to announce that we've wrapped up the initial work here, and all our Windows builds on Try are now happening in Amazon. The biggest win from this is that our

Re: Now measuring Firefox size per-commit. What else should we be tracking?

On Mon, Nov 9, 2015 at 6:39 PM, William Lachance wrote: > On 2015-11-06 5:56 PM, Mark Finkle wrote: > >> I also think measuring build times, and other build related stats, would >> be >> useful. I'd like to see Mozilla capturing those stats for developer builds >> though.

Re: Now measuring Firefox size per-commit. What else should we be tracking?

This is really great, thanks for adding support for this! I'd like to see the size of the complete updates measured as well, in addition to the installer sizes. Do we have alerts for these set up yet? Cheers, Chris On Wed, Nov 4, 2015 at 10:55 AM, William Lachance

Re: Partial updates temporarily disabled for Nightly and Dev-Edition

Partial updates should be functional again now. Sorry for the inconvenience! On Thu, Oct 29, 2015 at 4:49 PM, Chris AtLee <cat...@mozilla.com> wrote: > We've temporarily disabled generation of partial updates for Nightly and > Dev-Edition (Aurora) versions of Firefox. > > Give

Partial updates temporarily disabled for Nightly and Dev-Edition

We've temporarily disabled generation of partial updates for Nightly and Dev-Edition (Aurora) versions of Firefox. Given that Dev-Edition updates are currently frozen as part of our uplift process, the main impact of this is on Nightly users. We hope to have partial update generation re-enabled

Re: Per-test chaos mode now available, use it to help win the war on orange!

Very interesting, thank you! Would there be a way to add an environment variable or harness flag to run all tests in chaos mode? On Thu, Jun 4, 2015 at 5:31 PM, Chris Peterson cpeter...@mozilla.com wrote: On 6/4/15 11:32 AM, kgu...@mozilla.com wrote: I just landed bug 1164218 on inbound,

Re: It is now possible to apply arbitrary tags to tests/manifests and run all tests with a given tag

Sounds great! I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=1161282 for this. According to https://secure.pub.build.mozilla.org/builddata/reports/reportor/daily/highscores/highscores.html, we still have a ton of people using '-p all -u all' on try On Mon, May 4, 2015 at 5:12 PM,

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

On 17:26, Tue, 23 Sep, Kyle Huey wrote: On Tue, Aug 26, 2014 at 8:23 AM, Chris AtLee cat...@mozilla.com wrote: Just a short note to say that this experiment is now live on mozilla-inbound. ___ dev-tree-management mailing list dev-tree-managem

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

Just a short note to say that this experiment is now live on mozilla-inbound. signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

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

On 17:37, Wed, 20 Aug, Jonas Sicking wrote: On Wed, Aug 20, 2014 at 4:24 PM, Jeff Gilbert jgilb...@mozilla.com wrote: I have been asked in the past if we really need to run WebGL tests on Android, if they have coverage on Desktop platforms. And then again later, why B2G if we have Android.

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

On 18:25, Tue, 19 Aug, Ehsan Akhgari wrote: On 2014-08-19, 5:49 PM, Jonathan Griffin wrote: On 8/19/2014 2:41 PM, Ehsan Akhgari wrote: On 2014-08-19, 3:57 PM, Jeff Gilbert wrote: I would actually say that debug tests are more important for continuous integration than opt tests. At least in

Re: Always brace your ifs

On 17:37, Sat, 22 Feb, L. David Baron wrote: On Saturday 2014-02-22 15:57 -0800, Gregory Szorc wrote: On Feb 22, 2014, at 8:18, Kyle Huey m...@kylehuey.com wrote: If you needed another reason to follow the style guide: https://www.imperialviolet.org/2014/02/22/applebug.html Code coverage

Non-unified builds now running periodically on all trees

Starting today [1], you'll see a new symbol on TBPL: Bn. These are builds running with unified sources disabled. We're now running these periodically on 64-bit linux (opt and debug) on all trees on the same cadence as the PGO builds. The purpose of these builds is to catch build problems that

Re: Thinking about the merge with unified build

On 18:23, Mon, 02 Dec, Ehsan Akhgari wrote: As for identifying broken non-unified builds, can we configure one of our mozilla-inbound platforms to be non-unified (like 32-bit Linux Debug)? I think the answer to that question depends on how soon bug 942167 can be fixed. Chris, any ideas?

Re: Pushes to Backouts on Mozilla Inbound

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 dbu...@mozilla.com 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

Shutting off leak tests?

Hi! Leak tests on OSX have been failing intermittently for nearly a year now[1]. As yet, we don't have any ideas why they're failing, and nobody is working on fixing them. Would anybody be very sad if we shut them off? Are these tests providing useful information any more? If they are

Re: Proposal for an inbound2 branch

On 02:54, Tue, 30 Apr, Justin Lebar wrote: Is there sanity to this proposal or am I still crazy? If we had a lot more project branches, wouldn't that increase the load on infra dramatically, because we'd have less coalescing? Yes, it would decrease coalescing. I wonder how many tree closures

Re: Some data on mozilla-inbound

On 14:29, Fri, 26 Apr, Gregory Szorc wrote: On 4/26/2013 2:06 PM, Kartikaya Gupta wrote: On 13-04-26 11:37 , Phil Ringnalda wrote: Unfortunately, engineering is totally indifferent to things like having doubled the cycle time for Win debug browser-chrome since last November. Is there a bug

Re: Some data on mozilla-inbound

On 16:34, Tue, 23 Apr, Gervase Markham wrote: On 23/04/13 10:17, Ed Morley wrote: Given that local machine time scales linearly with the rate at which we hire devs (unlike our automation capacity), I think we need to work out why (some) people aren't doing things like compiling locally and

Re: New backout policy for Ts regressions on mozilla-inbound

On 18/10/12 06:44 PM, Justin Lebar wrote: Do we still have the bug where a test that finishes first, but is from a later cset (say a later cset IMPROVES Ts by 4% or more) would make us think we regressed it on an earlier cset if that earlier talos run finishes later? Such that we set graph

Re: try: -p all considered harmful?

On 30/09/12 03:43 AM, Justin Lebar wrote: We're all trying to build the best system we can here. We've been publishing as much raw data as we can, as well as reports like wait time data for ages. We're not trying to hide this stuff away. I understand. My point is just that the data we