It may be surprising, but hg.mozilla.org is still accepting plain text
connections via http://hg.mozilla.org/ and isn't redirecting them to
https://hg.mozilla.org/.
On February 1 likely around 0800 PST, all requests to http://hg.mozilla.org/
will issue an HTTP 301 Moved Permanently redirect to htt
http://hg.mozilla.org now HTTP 301s to https://hg.mozilla.org/. Please
report any problems against bug 450645 and/or make noise in #vcs on
irc.mozilla.org.
On Thu, Jan 26, 2017 at 2:17 PM, Gregory Szorc wrote:
> It may be surprising, but hg.mozilla.org is still accepting plain t
On Fri, Feb 3, 2017 at 7:11 AM, Ryan VanderMeulen wrote:
> A friendly reminder that per the MDN commit rules, the use of "No bug" in
> the commit message is to be used sparingly - in general for minor things
> like whitespace changes/comment fixes/etc where traceability isn't as
> important.
> ht
On Fri, Feb 3, 2017 at 12:52 PM, Emma Humphries wrote:
>
> Pulsebot has been suspended when we found it was spamming 5-digit bmo bugs
> about GitHub issues.
>
> There's a ticket to clean up bmo https://bugzilla.mozilla.org/
> show_bug.cgi?id=1336563 and I'll work with that team to get it cleaned
On Thu, Mar 9, 2017 at 1:53 PM, Mike Connor wrote:
> (please direct followups to dev-planning, cross-posting to governance,
> firefox-dev, dev-platform)
>
>
> Nearly 19 years after the creation of the Mozilla Project, commit access
> remains essentially the same as it has always been. We've evol
On Tue, Mar 21, 2017 at 7:44 PM, Boris Zbarsky wrote:
> On 3/21/17 6:41 PM, Jeff Gilbert wrote:
>
>> JSON allows comments if all the JSON processors we use handle comments. :)
>>
>
> JSON.parse in JS does not.
>
> The Python "json" module does not as far as I can tell.
>
> What JSON processors ar
; > their niche well. I have one at home now, so I'll test when I get a
> > chance.
> >
> > On Wed, Jul 6, 2016 at 12:06 PM, Trevor Saunders
> > wrote:
> >> On Tue, Jul 05, 2016 at 04:42:09PM -0700, Gregory Szorc wrote:
> >>> On Tue, Jul 5, 201
I recently reinstalled Windows 10 on one of my machines. This involved
visiting various web sites and downloading lots of software.
It is pretty common for software publishers to publish hashes or
cryptographic signatures of software so the downloaded software can be
verified. (Often times the dow
On Sun, Mar 26, 2017 at 11:56 PM, Jean-Yves Avenard
wrote:
> Hi.
>
> I have received the new Dell XPS 15 9560 and got very puzzled as to why
> compiling central was so slow on this machine.
> This is comparing against a Gigabyte Aero 14 with a gen 6 intel CPU
> (2.6Ghz i7-6600HQ) vs Dell's 7th ge
This message applies to anyone who clones a Firefox repository from
hg.mozilla.org. *Failure to read this message may result in degraded
Mercurial performance.* If you use git-cinnabar or use the mozilla-unified
repository exclusively, you are likely shielded from degraded performance
and can stop
I've seen a few follow-up questions in IRC and bug reports and would like
to clarify a few points. Content inline and below.
On Thu, Apr 6, 2017 at 4:13 PM, Gregory Szorc wrote:
> This message applies to anyone who clones a Firefox repository from
> hg.mozilla.org. *Failure to read t
On Mon, Apr 17, 2017 at 8:16 AM, Boris Zbarsky wrote:
> A quick reminder to patch authors and reviewers.
>
> Changesets should have commit messages. The commit message should
> describe not just the "what" of the change but also the "why". This is
> especially true in cases when the "what" is o
On Mon, Apr 17, 2017 at 4:10 PM, smaug wrote:
> On 04/17/2017 06:16 PM, Boris Zbarsky wrote:
>
>> A quick reminder to patch authors and reviewers.
>>
>> Changesets should have commit messages. The commit message should
>> describe not just the "what" of the change but also the "why". This is
>>
On Mon, Apr 17, 2017 at 5:12 PM, wrote:
> On Tuesday, April 18, 2017 at 11:58:11 AM UTC+12, smaug wrote:
> > On 04/18/2017 02:36 AM, Gregory Szorc wrote:
> > > On Mon, Apr 17, 2017 at 4:10 PM, smaug wrote:
> > >
> > >> On 04/17/2017 06:16 PM, Boris Zbarsky
On Mon, Apr 17, 2017 at 10:36 PM, Steve Fink wrote:
> On 04/17/2017 08:11 PM, Nicholas Nethercote wrote:
>
>> On Tue, Apr 18, 2017 at 11:34 AM, Ben Kelly wrote:
>>
>> I don't object to people writing longer commit messages, but that
>>> information needs to be in the bug. Our tools today (splin
On Fri, May 12, 2017 at 2:37 PM, Aaron Klotz wrote:
> On 5/12/2017 8:29 AM, Ryan VanderMeulen wrote:
>
>> And while we're on that topic, I'll also remind people once again that
>> for Windows MozillaBuild users, you can keep your copy of Mercurial up to
>> date via pip! Simply run |pip install -U
I thought there was a bug on file, but maybe not. I've long thought the
following changes should be made:
* `mach mercurial-setup` should be rolled into `mach bootstrap`
* `mach doctor` should be rolled into `mach bootstrap`
* `mach bootstrap` should remember answers from last time and not prompt
`mach build` attempts to parse compiler warnings to a persisted "database."
You can view a list of compiler warnings post build by running `mach
warnings-list`. The intent behind this feature was to make it easier to
find and fix compiler warnings. After all, something out of sight is out of
mind.
> > > Can we make some effort to get clean warnings output at the end of
> > > standard
> > > builds? A huge chunk of the warnings come from NSS and NSPR, and should
> > > be
> > > easily fixable. Most of the rest seem to come from vendored libraries,
> >
Mercurial 4.2 (just deployed to https://hg.mozilla.org/) contains a new
feature for visualizing the history of a subset of a file. Those of you who
perform a lot of code archeology may find it more useful than the classical
annotate/blame UI (which is based on whole files and single revisions and
c
;
> > > On Friday, May 26, 2017 at 6:03:02 AM UTC+12, Chris Peterson wrote:
> > > > On 2017-05-25 5:31 AM, Ehsan Akhgari wrote:
> > > > > On 05/19/2017 02:44 PM, Gregory Szorc wrote:
> > > > >> `mach build` attempts to parse compiler warnings to a p
to give developers a sense of progress. Teaching
the machines to estimate progress/ETA for us is a lot more work than
feeding a low-noise signal into the superb pattern recognition apparatus
that is the human brain.
>
> On Thu, May 25, 2017 at 8:31 PM, Ehsan Akhgari
> wrote:
>
&g
On Thu, May 25, 2017 at 5:31 AM, Ehsan Akhgari
wrote:
> On 05/19/2017 02:44 PM, Gregory Szorc wrote:
>
>> `mach build` attempts to parse compiler warnings to a persisted
>> "database."
>> You can view a list of compiler warnings post build by running `mach
&g
(Forwarding for Rob since he's not on these lists and can't post.)
Many of you have said that you want an easier way to reproduce what
automation is doing. Rob's work should make things a bit easier for Windows.
-- Forwarded message --
From: Rob Thijssen
Date: Tue, May 30, 2017 a
On Mon, Jun 19, 2017 at 7:06 PM, Jeff Muizelaar
wrote:
> Yes. I use Instruments on Nightly builds extensively. It would really
> be a loss to lose this functionality. I think it's important to weigh
> the performance improvements that we get from easy profiling against
> any advantage we get from
On Tue, Jun 20, 2017 at 10:28 AM, Ehsan Akhgari
wrote:
> On 06/20/2017 12:28 PM, Nathan Froyd wrote:
>
>> On Tue, Jun 20, 2017 at 12:19 PM, Ehsan Akhgari
>> wrote:
>>
>>> On 06/20/2017 08:34 AM, Nathan Froyd wrote:
>>>
There is some kind of interaction with the underlying machine (see
We're starting to enable the *building* (not enabling) of Stylo in various
platforms in automation. This means that Nightly will start shipping Stylo
bits soon - possibly the next Nightly if things stick.
The roll-out is being done as platforms are ready. Linux 64-bit and Windows
64-bit are the pr
On Wed, Jul 5, 2017 at 6:36 PM, Kris Maglione wrote:
> It's possible to use the preprocessor to join multiple JS files, but we've
> been moving away from that as much as possible recently.
>
It is worth mentioning that we don't like to use the Python preprocessor
because preprocessor syntax make
On Thu, Jul 13, 2017 at 6:04 PM, Mark Côté wrote:
> On 2017-07-13 3:54 PM, Randell Jesup wrote:
>
>> On Wed, Jul 12, 2017 at 11:27 AM, Byron Jones wrote:
>>>
>>> But indeed having also the patches in bugzilla would be good.
>
> no, it would be bad for patches to be duplicated into b
> On Jul 15, 2017, at 23:36, Gabriele Svelto wrote:
>
>> On 14/07/2017 05:39, Boris Zbarsky wrote:
>> I should note that with GitHub what this means is that you get
>> discussion on the PR that should have gone in the issue, with the result
>> that people following the issue don't see half the
On Mon, Jul 17, 2017 at 10:01 AM, Kris Maglione
wrote:
> On Mon, Jul 17, 2017 at 09:52:55AM -0700, Bobby Holley wrote:
>
>> On Mon, Jul 17, 2017 at 9:42 AM, Benjamin Smedberg > >
>> wrote:
>>
>> I don't know really anything about how rust panics get reflected into
>>> crash-data. Who would be the
On Thu, Jul 20, 2017 at 9:33 AM, James Graham
wrote:
> Bug 1341078 and dependencies just landed on inbound, which means we now
> have the W3C/web-platform-tests CSS tests in-tree and running in
> automation. This adds about 12,000 reftests for CSS features to the
> web-platform-tests suite. They
Thanks for all your work on this, Ryan!
So everyone knows, this is hopefully the last major overhaul of
MozillaBuild.
The plan from build system land is to attempt to go "all in" on Windows
Subsystem for Linux (WSL). That's the feature in Windows 10 (and even in
Server additions now) that impleme
On Sat, Jul 22, 2017 at 1:11 PM, Enrico Weigelt, metux IT consult <
enrico.weig...@gr13.net> wrote:
> Hi folks,
>
>
> the whole build seems to be very complex.
>
> Not just the huge configure.in, but also the complexity in moz.build
> files, many ifdef's, etc, etc. Many orthogonal things are twist
On Mon, Jul 24, 2017 at 6:13 PM, Enrico Weigelt, metux IT consult <
enrico.weig...@gr13.net> wrote:
> On 25.07.2017 00:32, Mike Hoye wrote:
>
>> On 2017-07-24 8:27 PM, Enrico Weigelt, metux IT consult wrote:
>>
>>> Hi folks,
>>>
>>>
>>> I see lots of #ifdef XP_OS2 ... is OS/2 still supported at al
Enrico,
We generally don't accept Firefox patches via email. Please visit
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Introduction
to learn about how to submit patches to Firefox.
On Mon, Jul 31, 2017 at 12:18 AM, Enrico Weigelt, metux IT consult <
enrico.weig...@gr13.net> wr
On Mon, Aug 7, 2017 at 11:01 PM, Henri Sivonen wrote:
> On Tue, Aug 8, 2017 at 1:12 AM, Mike Hommey wrote:
> > Here's a bunch of data why "let's switch compilers" is not necessarily
> > easy (I happen to have gathered that recently):
>
> Thank you.
>
> > Newer versions of clang-cl might generate
On Tue, Aug 8, 2017 at 5:42 PM, Kris Maglione wrote:
> One of my biggest frustrations in profiling startup performance has been
> the fact that exactly which code runs during before or after first paint
> changes based on arbitrary timing factors. If I make a 5ms improvement to
> one section of c
-- Forwarded message --
From: Gregory Szorc
Date: Thu, Aug 10, 2017 at 12:10 PM
Subject: Security releases for Git, Mercurial, and Subversion
To: Firefox Dev , dev-version-control <
dev-version-cont...@lists.mozilla.org>
Git, Mercurial, and Subversion just had a coord
On Thu, Aug 10, 2017 at 12:10 PM, Gregory Szorc wrote:
> Git, Mercurial, and Subversion just had a coordinated release to mitigate
> a security vulnerability regarding the parsing of ssh:// URLs. Essentially,
> well-crafted ssh:// URLs (e.g. in a subrepo, submodule, or svn:externals
>
On Mon, Aug 28, 2017 at 12:28 AM, Erxin Shang
wrote:
> Hi Mozilla Experts,
>
> I'm trying to build a release version Firefox. But after the build there
> seems still a little bit different compare to the official build. Such as
> the official build doesn't contain the folder chrome/, components/,
On Tue, Aug 29, 2017 at 7:07 PM, L. David Baron wrote:
> On Tuesday 2017-08-29 18:32 -0700, Eric Rahm wrote:
> > Do we explicitly state a preferred alignment of arguments in multi-line
> > function declarations (primarily in the context of C++) [1]? This
> question
> > has come up in regards to u
On Wed, Sep 6, 2017 at 2:10 PM, wrote:
> Over the last 9 months a few of us have really watched intermittent test
> failures almost daily and done a lot to pester people as well as fix many.
> While there are over 420 bugs that have been fixed since the beginning of
> the year, there are half tha
The Try Service ("Try") is a mechanism that allows developers to schedule
tasks in automation. The main API for that service is "Try Syntax" (e.g.
"try: -b o -p linux -u xpcshell"). And the transport channel for making
that API call is a Mercurial changeset's commit message plus a version
control "
On Fri, Sep 15, 2017 at 3:39 PM, Botond Ballo wrote:
> Will submitting to try from MozReview (or Phabricator once that
> replaces MozReview) still work? I think there is important value in
> being able to submit to try without a local checkout.
>
Yes. And I agree there is value in scheduling aut
Git users can pile on and let your numbers be known.
But please do it in the bug and not on this list.
> On Fri, Sep 15, 2017 at 3:30 PM, Gregory Szorc wrote:
>
>> The Try Service ("Try") is a mechanism that allows developers to schedule
>> tasks in automation. The
run a browser in their development
environment anyway).
But I digress: that site should continue to run.
>
> On Sat, Sep 16, 2017 at 8:30 AM, Gregory Szorc wrote:
>
>> The Try Service ("Try") is a mechanism that allows developers to schedule
>> tasks in automation. The
On Fri, Sep 15, 2017 at 6:58 PM, Boris Zbarsky wrote:
> On 9/15/17 6:30 PM, Gregory Szorc wrote:
>
>> we'd like to require the use of `mach try` for Try
>> submissions.
>>
>
> So just to be clear, instead of being able to "hg push -f try" will one
&
On Fri, Sep 15, 2017 at 7:44 PM, Eric Rescorla wrote:
> What happens if you are using git?
>
git-cinnabar is already supported.
Vanilla git is TBD. I see bug 1400470 was just filed for that.
>
> On Fri, Sep 15, 2017 at 3:30 PM, Gregory Szorc wrote:
>
>> The Try
On Fri, Sep 15, 2017 at 8:37 PM, Eric Rescorla wrote:
>
>
> On Fri, Sep 15, 2017 at 8:33 PM, Gregory Szorc wrote:
>
>> On Fri, Sep 15, 2017 at 7:44 PM, Eric Rescorla wrote:
>>
>>> What happens if you are using git?
>>>
>>
>> git-cinnabar is
On Fri, Sep 15, 2017 at 10:21 PM, ISHIKAWA,chiaki
wrote:
> Does "mozilla/mach try" will work for try-comm-central?
>
> (Well, I know there has been a general talk of moving thunderbird to
> somewhere else, but it is not going to happen overnight.)
>
I'm not sure. There's no good reason why it sh
A few posts here and in the other thread have mentioned abstracting away
complexity to servers as if it is a magical solution that makes all
problems go away.
Yes, deploying a server-side solution to do some "syncing" is doable and
solves a subset of notable problems.
But I advise extreme caution
On Tue, Sep 26, 2017 at 6:45 PM, Nicholas Hurley wrote:
> So I'm going to chime in on a formatting discussion for probably the second
> time in my life as a mozillian. (It's apparently that important to me.)
>
> On Tue, Sep 26, 2017 at 9:25 AM, Mats Palmgren wrote:
>
> > 2. touching more lines t
On Wed, Sep 27, 2017 at 11:58 AM, Gregory Szorc wrote:
> On Tue, Sep 26, 2017 at 6:45 PM, Nicholas Hurley
> wrote:
>
>> So I'm going to chime in on a formatting discussion for probably the
>> second
>> time in my life as a mozillian. (It's apparently that i
On Tue, Oct 17, 2017 at 9:58 PM, wrote:
> This is awesome! As an engineer who has to work with C++ until we advance
> Rust bindings, I always feel terrible when my reviewers spend their
> precious time identifying simple C++ errors in my code.
>
>
> Seeing the advancements in static analysis for
On Wed, Oct 18, 2017 at 10:28 AM, David Teller wrote:
> Hi everyone,
>
> Yesterday, Nightly was broken on Linux and MacOS because of a typo in
> JS code [1]. If I understand correctly, this triggered the usual
> "undefined is not a function", which was
>
> 1/ uncaught during testing, as the
On Thu, Oct 19, 2017 at 5:37 PM, Andreas Tolfsen wrote:
> Some time ago there was a discussion on dev-builds@ regarding
> the state of our in-tree source code documentation. The main
> focus was that MDN, moving forward, will mainly revolve around web
> platform documentation and would actively
On Thu, Oct 19, 2017 at 6:48 PM, Daniel Veditz wrote:
> On Thu, Oct 19, 2017 at 9:30 AM, smaug wrote:
>
> > (Hoping the r=documentation flag won't be misused ;))
>
>
> I hope there will be some kind of hook making sure files touched in that
> manner are all actually documentation files and not
Compiling Rust code with optimizations is significantly slower than
compiling without optimizations. As was measured in bug 1411081, the
difference between rustc's -Copt-level 1 and 2 on an i7-6700K (4+4 cores)
for a recent revision of mozilla-central was 325s/802s wall/CPU versus
625s/1282s. This
On Wed, Oct 25, 2017 at 11:50 AM, Emilio Cobos Álvarez
wrote:
>
>
> On 10/25/2017 07:59 PM, Boris Zbarsky wrote:
> > On 10/25/17 1:34 PM, Gregory Szorc wrote:
> >> Also, due to ongoing work around Rust integration in the build system,
> it
> >> is dangerous t
On Wed, Oct 25, 2017 at 10:34 AM, Gregory Szorc wrote:
> Compiling Rust code with optimizations is significantly slower than
> compiling without optimizations. As was measured in bug 1411081, the
> difference between rustc's -Copt-level 1 and 2 on an i7-6700K (4+4 cores)
> for
e filed bug 1412077 to track
improvements here.
>
> On Wed, Oct 25, 2017 at 1:34 PM, Gregory Szorc wrote:
> > Compiling Rust code with optimizations is significantly slower than
> > compiling without optimizations. As was measured in bug 1411081, the
> > difference between r
On Thu, Oct 26, 2017 at 6:34 AM, Henri Sivonen wrote:
> On Thu, Oct 26, 2017 at 9:15 AM, Henri Sivonen
> wrote:
> > There's a huge downside, though:
> > If the screen stops consuming the DisplayPort data stream, the
> > graphical session gets killed! So if you do normal things like turn
> > the
On Thu, Oct 26, 2017 at 4:31 PM, Mike Hommey wrote:
> On Thu, Oct 26, 2017 at 04:02:20PM -0700, Gregory Szorc wrote:
> > Also, the machines come with Windows by default. That's by design: that's
> > where the bulk of Firefox users are. We will develop better products if
client.mk has existed since 1998 (
https://hg.mozilla.org/experimental/mozilla-central-cvs/rev/0a5e1fa423bd).
Before `mach`, client.mk was the recommended way to build Firefox and
perform other build tasks. client.mk has rarely changed in recent years
because the build system maintainers have been
gt; mind here as the i9's do not support ECC memory. That may have to be a
> separate system with a Xeon.
>
> On Fri, Oct 27, 2017 at 3:58 PM, Gabriele Svelto
> wrote:
>
>> On 27/10/2017 01:02, Gregory Szorc wrote:
>> > Sophana (CCd) is working on a new system bu
WebRender becomes unusable opt-level=1. It also looks like style
> > performance takes quite a hit as well which means that our default
> > developer builds become unusable for performance work. I worry that
> > people will forget this and end up rediscovering only when they look
On Tue, Oct 24, 2017 at 11:59 AM, Gregory Szorc wrote:
> Freshly landed in bug 1411343, CI now produces JSON files containing info
> about how source files map to Bugzilla components.
>
> You'll notice a new "Bugzilla" task in Treeherder. It will write some
> a
On Thu, Nov 2, 2017 at 3:43 PM, Nico Grunbaum wrote:
> For rr I have an i7 desktop with a base clock of 4.0 Ghz, and for building
> I use icecc to distribute the load (or rather I will be again when bug
> 1412240[0] is closed). The i9 series has lower base clocks (2.8 Ghz, and
> 2.6Ghz for the t
> On Nov 6, 2017, at 05:19, Gabriele Svelto wrote:
>
>> On 04/11/2017 01:10, Jeff Gilbert wrote:
>> Clock speed and core count matter much more than ECC. I wouldn't chase
>> ECC support for general dev machines.
>
> The Xeon-W SKUs I posted in the previous thread all had identical or
> higher
This thread is good feedback. I think changing the default to a 1TB SSD is
a reasonable request.
Please send any future comments regarding hardware to Sophana (
s...@mozilla.com) to increase the chances that feedback is acted on.
On Wed, Nov 8, 2017 at 9:09 AM, Julian Seward wrote:
> On 08/11/1
For reasons outlined at
https://bugzilla.mozilla.org/show_bug.cgi?id=1388447#c7, we would like to
make Python 3 a requirement to build Firefox sometime in the Firefox 59
development cycle. (Firefox 59 will be an ESR release.)
The requirement will likely be Python 3.5+. Although I would love to mak
e IDEs
more useful.
If you do perf hacking in Python, Python 3 also has a slew of new
facilities for memory and CPU profiling.
There's also a ton of random package additions and improvements in the
standard library. And of course tons of small bug fixes.
>
> On Sat, Nov 11, 2017, at 10:2
On Fri, Nov 10, 2017 at 7:43 PM, Mike Hommey wrote:
> On Fri, Nov 10, 2017 at 05:42:01PM -0800, Gregory Szorc wrote:
> > On Fri, Nov 10, 2017 at 4:22 PM, Xidorn Quan wrote:
> >
> > > I'm happy hearing this. I would be interested on whether we are going
> to
>
On Fri, Oct 27, 2017 at 4:16 PM, Gregory Szorc wrote:
> client.mk has existed since 1998 (https://hg.mozilla.org/
> experimental/mozilla-central-cvs/rev/0a5e1fa423bd). Before `mach`,
> client.mk was the recommended way to build Firefox and perform other
> build tasks. client.m
> On Nov 30, 2017, at 04:40, Anne van Kesteren wrote:
>
>> On Wed, Nov 29, 2017 at 9:47 PM, Dave Townsend wrote:
>> If you’re working on improving storage or syncing of data in any of our
>> products or projects, on any platform, or if you’re currently struggling to
>> work with what currently
On Wed, Nov 29, 2017 at 11:40 AM, Mark Côté wrote:
> On Wednesday, 29 November 2017 12:43:58 UTC-5, Steve Fink wrote:
> > On 11/29/2017 08:35 AM, Mark Côté wrote:
> > > I posted an update on Phabricator and Lando to my blog a couple weeks
> ago, but I figured I should share it here too:
> https:
On Wed, Nov 29, 2017 at 5:09 PM, Karl Tomlinson wrote:
> I've always found this confusing, and so I'll write down the
> understanding I've reached, in the hope that either it will help
> others, or others can help me by correcting if these are
> misunderstandings.
>
> On Unix systems:
>
> `nati
On Mon, Dec 4, 2017 at 5:00 PM, Gregory Szorc wrote:
> On Wed, Nov 29, 2017 at 5:09 PM, Karl Tomlinson wrote:
>
>> I've always found this confusing, and so I'll write down the
>> understanding I've reached, in the hope that either it will help
>> others,
On Mon, Dec 4, 2017 at 7:22 PM, Robert O'Callahan
wrote:
> On Tue, Dec 5, 2017 at 2:00 PM, Gregory Szorc wrote:
>
>> Many programming languages paper over these subtle differences leading to
>> badness. For example, the preferred path APIs for Python and Rust assume
>
Yes, most of the build time regressions in 2017 came from Rust. Leaning
more heavily on C++ features that require more processing or haven't been
optimized as much as C++ features that have been around for years is likely
also contributing.
Enabling sccache allows Rust compilations to be cached, w
On Tue, Jan 16, 2018 at 1:42 PM, Ted Mielczarek wrote:
> On Tue, Jan 16, 2018, at 10:51 AM, Jean-Yves Avenard wrote:
> > Sorry for resuming an old thread.
> >
> > But I would be interested in knowing how long that same Lenovo P710
> > takes to compile *today*….> In the past 6 months, compilation
On Mon, Feb 12, 2018 at 6:09 AM, Boris Zbarsky wrote:
> On 2/11/18 3:57 PM, Emilio Cobos Álvarez wrote:
>
>> Arc wants to use something like:
>>
>
> So from my point of view, having the bug# easily linked from various
> places where the short summary is all that's shown (pushlogs especially) is
>
On Fri, Mar 9, 2018 at 7:28 AM, David Teller wrote:
> I'll need a license review for a vendored Rust package. Who can perform
> these reviews these days?
>
We have an allow list of licenses in our Cargo config. So if the license is
already allowed, you can reference the crate in a Cargo.toml and
Bug 1406536 has the context.
I should note that we now have shiny new components for aspects of the
build workflow including bootstrapping, linting, static analysis, generated
documentation, and CI task configuration. I encourage people to look at
those components at
https://bugzilla.mozilla.org/e
On Tue, Mar 27, 2018 at 3:44 AM, Henri Sivonen wrote:
> I'm having trouble finding reliable information about the performance
> of unaligned NEON memory access on ARMv7 phones.
>
> What I can find is:
>
> * ARMv7 seems to allow unaligned access to be a trap-to-kernel kind
> of performance disast
On Fri, Nov 10, 2017 at 3:27 PM, Gregory Szorc wrote:
> For reasons outlined at https://bugzilla.mozilla.org/s
> how_bug.cgi?id=1388447#c7, we would like to make Python 3 a requirement
> to build Firefox sometime in the Firefox 59 development cycle. (Firefox 59
> will be an ESR relea
On Mon, Apr 9, 2018 at 9:52 PM, Mike Hommey wrote:
> On Tue, Apr 10, 2018 at 02:46:40PM +1000, Martin Thomson wrote:
> > This seems like a good idea.
> >
> > Please consider adding hg.mozilla.org to your list of things you will
> > clone from. That will allow us to remove some ugly hacks from th
On Fri, Apr 20, 2018 at 2:51 PM, L. David Baron wrote:
> On Friday 2018-04-20 14:23 -0700, Kris Maglione wrote:
> > For a lot of these patches, my opinion is only really critical for
> certain
> > architectural aspects, or implementation aspects at a few critical
> points.
> > There are other rev
gly undermine general support for the build system team and jeopardize
our ability to make meaningful changes.
>
>> On 10/25/17 7:34 PM, Gregory Szorc wrote:
>> Compiling Rust code with optimizations is significantly slower than
>> compiling without optimizations. As was m
On May 10, 2018, at 06:47, Randell Jesup wrote:
>>> On Thu, Apr 26, 2018, at 12:41 AM, Mark Côté wrote:
>>> How we might use blocking reviewers in our workflow is still open, but
>>> it could be used for training up reviewers, in which case the trainee
>>> would be a regular reviewer and the
On Wed, May 9, 2018 at 11:01 AM, Ted Mielczarek wrote:
> On Wed, May 9, 2018, at 1:11 PM, L. David Baron wrote:
> > > mozregression won't be able to bisect into inbound branches then, but I
> > > believe we've always been expiring build artifacts created from
> integration
> > > branches after a
On Thu, May 10, 2018 at 5:35 PM, Anthony Jones wrote:
> You may already know that the Low-Level Tools team support important tools
> and code infrastructure. Lately we’ve also been improving our rustc/clang
> (LLVM) story and I’d like bring everyone up to date.
>
> There are a lot of important an
On Fri, May 11, 2018 at 7:47 PM, Boris Zbarsky wrote:
> On 5/11/18 7:06 PM, Gregory Szorc wrote:
>
>> Artifact retention and expiration boils down to a
>> trade-off between the cost of storage and the convenience of accessing
>> something immediately (as opposed to waiti
On Tue, May 29, 2018 at 1:48 PM, Jeff Gilbert wrote:
> It would be sad to see us standardize on a clang monoculture.
>
I am sympathetic to that concern. (I have similar monoculture fears that
the open source world is over-pivoting towards non-OSS platforms like
GitHub and Slack as well.)
We wil
On Wed, May 30, 2018 at 10:08 AM, Justin Wood wrote:
> Hello Everyone,
>
> tl;dr You should now see "L10n" jobs on treeherder with many pushes, these
> are tier 1 and if they break they would also be breaking Nightly so your
> patch would need to be backed out.
>
> As many of you know, especially
On Tue, Jun 26, 2018 at 3:45 PM, Dave Townsend
wrote:
> On Tue, Jun 26, 2018 at 3:06 PM Sebastian Hengst wrote:
>
> > Original-Nachricht
> > Betreff: Re: mozilla-inbound backout policy subject to change (become
> > similar to autoland)
> > Von: Boris Zbarsky
> > Datum: 2018-06
On Sun, Jul 1, 2018 at 6:59 PM, Geoff Lankow wrote:
> On comm-central we have a number of extensions that get built alongside
> everything else, but are not shipped. (That is, building produces a .xpi
> file in objdir/dist/xpi-stage.) I'd like to be able to have them uploaded
> as build artefacts
On Tue, Jul 10, 2018 at 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
> anything that might be fallout from this change. I'm especially
> interested in he
> On Aug 5, 2015, at 08:12, Ted Mielczarek wrote:
>
> Our Universal Mac builds are a frequent headache for build system work,
> being a special snowflake in many ways. They also use twice as much
> machine time as other builds, since they do a separate build for each
> architecture. I think it'
1 - 100 of 640 matches
Mail list logo
