still being closed. There is another TCW in 3
weeks where we hope to try again, provided we understand the upgrade
performance better.
Thanks for your patience.
cheers,
--
coop
On Fri, Jul 17, 2020 at 7:04 PM Chris Cooper wrote:
>
> Just a reminder that this TCW is happening *tomorrow*, J
Just a reminder that this TCW is happening *tomorrow*, July 18.
Trees will be closed for 12 hours for Taskcluster database updates
starting at 1400 UTC.
As always, if we can open the trees early, we will.
cheers,
--
coop
On Fri, Jul 3, 2020 at 3:37 PM Chris Cooper wrote:
>
> Hey all,
Hey all,
We will be having a TCW on Saturday, July 18. The trees will close at
1400 UTC and will be down for approximately 12 hours.
The only work that is currently planned is Phase 2 of the Taskcluster
database migration. Phase 1 was completely successfully back in
April[1].
Taskcluster for fir
t URL at
> https://github.com/mozilla/mozregression/blob/3df977cf7b9c50bdbe8495cde17baeb6c5724be2/mozregression/config.py#L23
> which gets used. It would be valuable to ensure mozregression can
> continue bisecting old builds after this decommissioning happens.
>
> On Thu, Jun 25,
d artifacts.
If you are one of the few individuals who does access artifacts from
the legacy cluster and haven't already spoken to us about
alternatives, please reach out before next Thursday.
Note: this will *not* affect day-to-day CI on either the Firefox CI or
Community clusters at all.
On Monday, November 4, 2019 at 5:00:17 PM UTC-5, Chris Cooper wrote:
>
> tl;dr:
>
> Taskcluster, the platform supporting Firefox CI, will be moving to a new
> hosting environment during the tree closing window (TCW) this coming
> Saturday, Nov 9. Trees will be closed from
g/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Simple_Thunderbird_build
>
> I've been searching everywhere I could think of for a solution to the below
> error with no success and I'm not sure where to go from here.
>
> Any suggestions?
>
> Thank you,
>
re I could think of for a solution to the below
error with no success and I'm not sure where to go from here.
Any suggestions?
Thank you,
Chris
$ ./mach build
Config object not found by mach.
0:24.82 Clobber not needed.
0:24.89 Adding make options from f:\mozilla-source\mozconfig
How does the performance of clang-cl builds compare to MSVC builds on
benchmarks like Speedometer?
On 2018-07-10 1:29 PM, David Major wrote:
Bug 1443590 is switching our official Windows builds to use clang-cl
as the compiler.
Please keep an eye out for regressions and file a blocking bug for
On Wed, Oct 11, 2017 at 1:46 PM, Nathan Froyd wrote:
> Does this user have a bugzilla :alias so that folks submitting patches
> via MozReview or similar can just write r=build-peer or something,
> rather than having to manually select the appropriate shared queue
> after submitting their patch for
Many of the build peers have long review queues. I'm not convinced
that all of the review requests going to any particular build peer
need to be exclusive. We're going to try an experiment to see if we
can make this better for patch authors and reviewers alike. To this
end, we've set up a shared re
The Stylo team would like to make libclang a build-time dependency so we
can generate C++/Rust bindings as part of the local build. We need
libclang 3.8+ on Mac and Linux and libclang 3.9+ on Windows.
This is Build Config bug 1310852.
___
dev-builds m
roject
file that works.
Unless someone complains (and I bet they won't given the lack of
response in this thread), we should backout bug 1122812. There are
others on my team affected by this too.
Cheers,
Chris Pearce.
On 2/21/2015 10:05 AM, Nathan Froyd wrote:
Hi all,
When discussing t
On 2014-03-11, 2:07 PM, Ben Hearsum wrote:
> On 03/11/14 01:51 PM, Gregory Szorc wrote:
>> The only major question I have is over the impact to release automation.
>> I'm not sure to what degree they rely on MozillaBuild, if any. We want
>> the build environments to remain as similar as possible to
I've seen this once before:
https://bugzilla.mozilla.org/show_bug.cgi?id=951968
Apparently, using NDK r8e and SDK v16 fixed the problem. Perhaps some funky
Mac-specific bug? Is the victim in this case using a Mac? Perhaps we can
get together enough information to figure out which versions of the
15 matches
Mail list logo
