Re: What is future of editor mode-lines after the switch to clang-format?

On Wed, Dec 5, 2018 at 5:51 AM Ehsan Akhgari wrote: > On Fri, Nov 30, 2018 at 8:23 PM Ehsan Akhgari > wrote: > >> On Fri, Nov 30, 2018 at 4:08 PM Gregory Szorc wrote: >> >>> On Fri, Nov 30, 2018 at 10:00 AM wrote: >>> >>> > Now that all of m

Re: Upcoming changes to our C++ Coding Style

On Fri, Dec 7, 2018 at 1:57 PM Botond Ballo wrote: > On Fri, Dec 7, 2018 at 11:36 AM Sylvestre Ledru > wrote: > > In the meantime, we will be running a bot weekly to reformat the > > mistakes and add the changeset into the ignore lists. > > But in the long run this won’t be sustainable, so once

Re: What is future of editor mode-lines after the switch to clang-format?

On Fri, Nov 30, 2018 at 10:00 AM wrote: > Now that all of mozilla-central is been migrated to use clang-format > automated code formatting, the question of what should happen with editor > modelines at the top of files should be considered. > >

Notice of hg.mozilla.org x509 certificate change on 2018-10-31

hg.mozilla.org's x509 server certificate (AKA an "SSL certificate") will be rotated around 2018-10-31T17:00 UTC (10:00 PDT). That's less than 24 hours from now. Bug 1495464 tracks. You may have the certificate's fingerprint pinned in your hgrc files. Automated jobs may pin the fingerprint as

Re: Using clang-cl to ship Windows builds

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

Re: Getting files from builders to test machines

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

Re: mozilla-inbound backout policy subject to change (become similar to autoland)

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:

Re: Localized Repacks now visible on (most) pushes

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,

Re: Update on rustc/clang goodness

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

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

On Fri, May 11, 2018 at 7:47 PM, Boris Zbarsky <bzbar...@mit.edu> 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 imme

Re: Update on rustc/clang goodness

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

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

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 >

Re: Is super-review still a thing?

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

Re: Default Rust optimization level decreased from 2 to 1

seemingly 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.

Re: Is super-review still a thing?

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. > >

Re: Intent To Require Manifests For Vendored Code In mozilla-central

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

Re: Intent to require Python 3 to build Firefox 59 and later

On Fri, Nov 10, 2017 at 3:27 PM, Gregory Szorc <g...@mozilla.com> 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 &

Re: Unaligned NEON memory access on ARMv7 phones

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

Re: PSA: Core::Build Config has moved

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

Re: Who can review licenses these days?

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

Re: Commit messages in Phabricator

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

Re: Faster gecko builds with IceCC on Mac and Linux

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

Re: Faster gecko builds with IceCC on Mac and Linux

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,

Re: Please do not use GetNativePath and GetNativeTarget in XP code and Windows-specific code

On Mon, Dec 4, 2017 at 7:22 PM, Robert O'Callahan <rob...@ocallahan.org> wrote: > On Tue, Dec 5, 2017 at 2:00 PM, Gregory Szorc <g...@mozilla.com> wrote: > >> Many programming languages paper over these subtle differences leading to >> badness. For example, the

Re: Please do not use GetNativePath and GetNativeTarget in XP code and Windows-specific code

On Mon, Dec 4, 2017 at 5:00 PM, Gregory Szorc <g...@mozilla.com> wrote: > On Wed, Nov 29, 2017 at 5:09 PM, Karl Tomlinson <mozn...@karlt.net> wrote: > >> I've always found this confusing, and so I'll write down the >> understanding I've reached, in the hope that

Re: Please do not use GetNativePath and GetNativeTarget in XP code and Windows-specific code

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

Re: Phabricator/Lando update, November 2017

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

Re: Browser Architecture Newsletter 5

> 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

Re: Intent to remove client.mk

On Fri, Oct 27, 2017 at 4:16 PM, Gregory Szorc <g...@mozilla.com> 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 > buil

Re: Intent to require Python 3 to build Firefox 59 and later

On Fri, Nov 10, 2017 at 7:43 PM, Mike Hommey <m...@glandium.org> 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 <m...@upsuper.org> wrote: > > > > > I'm happy hearing this. I would b

Re: Intent to require Python 3 to build Firefox 59 and later

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:27 AM, Gregor

Intent to require Python 3 to build Firefox 59 and later

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

Re: Bigger hard drives wanted (was Re: More ThinkStation P710 Nvidia tips (was Re: Faster gecko builds with IceCC on Mac and Linux))

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

Re: More ThinkStation P710 Nvidia tips (was Re: Faster gecko builds with IceCC on Mac and Linux)

> 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

Re: More ThinkStation P710 Nvidia tips (was Re: Faster gecko builds with IceCC on Mac and Linux)

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

Re: Mapping source files to Bugzilla components

On Tue, Oct 24, 2017 at 11:59 AM, Gregory Szorc <g...@mozilla.com> 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

Re: Default Rust optimization level decreased from 2 to 1

up rediscovering only when they look > > at profiles (as mstange just did). What's the use case for a > > --enable-optimize, opt-level=1 build? > > > > -Jeff > > > > On Wed, Oct 25, 2017 at 1:34 PM, Gregory Szorc <g...@mozilla.com> wrote: > >> Compi

Re: More ThinkStation P710 Nvidia tips (was Re: Faster gecko builds with IceCC on Mac and Linux)

ystem build we have in > 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 <gsve...@mozilla.com> > wrote: > >> On 27/10/2017 01:02, Gregory Szorc wrote: >> >

Intent to remove client.mk

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

Re: More ThinkStation P710 Nvidia tips (was Re: Faster gecko builds with IceCC on Mac and Linux)

On Thu, Oct 26, 2017 at 4:31 PM, Mike Hommey <m...@glandium.org> 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 de

Re: More ThinkStation P710 Nvidia tips (was Re: Faster gecko builds with IceCC on Mac and Linux)

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!

Re: Default Rust optimization level decreased from 2 to 1

filed bug 1412077 to track improvements here. > > On Wed, Oct 25, 2017 at 1:34 PM, Gregory Szorc <g...@mozilla.com> wrote: > > Compiling Rust code with optimizations is significantly slower than > > compiling without optimizations. As was measured in bug 1411081, the > >

Re: Default Rust optimization level decreased from 2 to 1

On Wed, Oct 25, 2017 at 10:34 AM, Gregory Szorc <g...@mozilla.com> 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-6

Re: Default Rust optimization level decreased from 2 to 1

On Wed, Oct 25, 2017 at 11:50 AM, Emilio Cobos Álvarez <emi...@crisal.io> 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 &g

Default Rust optimization level decreased from 2 to 1

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

Re: Reviews for in-tree documentation (was: Builds docs on MDN)

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

Re: Reviews for in-tree documentation (was: Builds docs on MDN)

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

Re: We need better canaries for JS code

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

Re: Intent to Enable: Automated Static Analysis feedback in MozReview

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

Re: Coding style: Argument alignment

On Wed, Sep 27, 2017 at 11:58 AM, Gregory Szorc <g...@mozilla.com> wrote: > On Tue, Sep 26, 2017 at 6:45 PM, Nicholas Hurley <hur...@mozilla.com> > wrote: > >> So I'm going to chime in on a formatting discussion for probably the >> second >> time in m

Re: Coding style: Argument alignment

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

Re: Canonical cinnabar repository

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

Re: Intent to require `mach try` for submitting to Try

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

Re: Intent to require `mach try` for submitting to Try

On Fri, Sep 15, 2017 at 7:44 PM, Eric Rescorla <e...@rtfm.com> 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 <g.

Re: Intent to require `mach try` for submitting to Try

On Fri, Sep 15, 2017 at 6:58 PM, Boris Zbarsky <bzbar...@mit.edu> 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 t

Re: Intent to require `mach try` for submitting to Try

or those who can 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 <g...@mozilla.com> wrote: > >> The Try Service ("Try") is a mechanism that allows developers to s

Re: Intent to require `mach try` for submitting to Try

here with the link so non-cinnabar 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 <g...@mozilla.com> wrote: > >> The Try Service ("Try") is a mechanism that allows de

Re: Intent to require `mach try` for submitting to Try

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

Intent to require `mach try` for submitting to Try

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

Re: Intermittent oranges and when to disable the related test case - a simplified policy

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

Re: Coding style: Argument alignment

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

Re: How to configure mozilla Firefox build options to build a customized release/developer edition build?

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

Fwd: Security releases for Git, Mercurial, and Subversion

-- Forwarded message -- From: Gregory Szorc <g...@mozilla.com> Date: Thu, Aug 10, 2017 at 12:10 PM Subject: Security releases for Git, Mercurial, and Subversion To: Firefox Dev <firefox-...@mozilla.org>, dev-version-control < dev-version-cont...@lists.mozilla.org>

Re: Figuring out and controlling what tasks run before first paint

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

Re: More Rust code

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. > > >

Re: OS/2 still supported ?

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

Re: build complexity vs kbuild

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

Re: Announcing MozillaBuild 3.0 Release

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

Re: wpt CSS tests now running on Linux

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 >

Re: Care in the use of MOZ_CRASH_UNSAFE_* macros: data review needed

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

Re: Phabricator Update, July 2017

> 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

Re: Phabricator Update, July 2017

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

Re: inlining JS code at build time

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

Stylo bits coming to a Nightly near you

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

Re: Profiling nightlies on Mac - what tools are used?

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

Re: Profiling nightlies on Mac - what tools are used?

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 >

Fwd: [tools-tc] TaskCluster Windows Loaners

(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

Re: Improving visibility of compiler warnings

017 at 4:03 PM, <gsquel...@mozilla.com> wrote: > > > > > 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: > > > >

View the history of line ranges on hg.mozilla.org

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

Re: Improving visibility of compiler warnings

> > > > 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 libra

Improving visibility of compiler warnings

`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.

Re: Have you run 'mach bootstrap' lately?

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

Re: Have you run 'mach bootstrap' lately?

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!

Re: A reminder about commit messages: they should be useful

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

Re: A reminder about commit messages: they should be useful

On Mon, Apr 17, 2017 at 5:12 PM, <gsquel...@mozilla.com> 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 <sm...@welho.com> wrote: > > &g

Re: A reminder about commit messages: they should be useful

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

Re: A reminder about commit messages: they should be useful

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

Re: Changes to Firefox repositories on hg.mozilla.org

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 <g...@mozilla.com> wrote: > This message applies to anyone who clones a Firefox repository from > hg.mozilla.o

Changes to Firefox repositories on hg.mozilla.org

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

Re: windows build anti-virus exclusion list?

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

Better download security through browsers

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

Re: Faster gecko builds with IceCC on Mac and Linux

chips do. It should fit > > 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 > > <tbsaunde+mozi...@tbsaunde.org> wrote: > >> On Tue, Jul 05, 2016 at 04:42:09PM -07

Re: Please do NOT hand-edit web platform test MANIFEST.json files

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

Re: The future of commit access policy for core Firefox

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

Re: Pulsebot has been given a major game misconduct penalty

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

Re: Please don't abuse "No bug" in commit messages

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

Re: Redirecting http://hg.mozilla.org/ to https://

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 <g...@mozilla.com> wrote: > It may be surprising, but hg.mozilla.org is still accept

Redirecting http://hg.mozilla.org/ to https://

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

Intent to vendor Servo in mozilla-central

Over in bug 1322769, we're planning to vendor the contents of the Servo Git repository into mozilla-central as part of Quantum efforts. The initial vendoring of the Servo repository is the first milestone of a larger project that aims to "unify" workflows and automation across the two projects,

Windows CPU power settings

I've been assessing new hardware options for Mozilla to issue to developers. As part of evaluating some dual socket Xeon processors, I found some unexpected behavior: these processors routinely underclock in Windows 10 unless several cores or are used. Contrast with the behavior of my i7 Skylake

  1   2   3   4   5   6   >