Faster blame on hg.mozilla.org / mozilla-central repo with CVS history

I'm pleased to announce the immediate availability of 2 new features on hg.mozilla.org: faster blame rendering and a mozilla-central repo with CVS history. You can find these features at: * https://hg.mozilla.org/experimental/mozilla-central-gd *

Re: autoland cleanup

On Wed, Nov 30, 2016 at 1:24 PM, Karl Tomlinson <mozn...@karlt.net> wrote: > Gregory Szorc writes: > > > On Wed, Nov 30, 2016 at 12:40 PM, Karl Tomlinson <mozn...@karlt.net> > wrote: > >> When history is rewritten, is there a way to view the original > &

Re: autoland cleanup

On Wed, Nov 30, 2016 at 12:40 PM, Karl Tomlinson <mozn...@karlt.net> wrote: > Gregory Szorc writes: > > > When the autoland repository was introduced, it was advised to not pull > > from this repository because we plan to do rewrites like this frequently > in > >

autoland cleanup

There was a sub-optimal landing in the autoland repository. Long story short, we rewrote a handful of changesets on the autoland repository and their corresponding pushlog entries. Accidental fallout from the rewrite was all autoland requests queued since the tree was closed ~14 hours ago failed.

Re: Rust required to build Gecko

> On Nov 27, 2016, at 14:46, Gerald Squelart wrote: > >> On Saturday, November 26, 2016 at 3:59:05 AM UTC+11, Ralph Giles wrote: >> On Fri, Nov 25, 2016 at 7:48 AM, Andrew Halberstadt >> wrote: >> >>> For anyone confused by this, the binaries are

Visual Studio 2017

Microsoft announced Visual Studio 2017 RC today. As always, there are some compelling reasons to support the new version. They have blogged extensively about performance improvements around compiling/linking and IDE interactions, which are always exciting. If you install VS2017 RC today,

Re: Fixing mach error colorization in emacs compilation buffers

On Wed, Nov 16, 2016 at 11:02 AM, Kyle Machulis wrote: > Pass-thru of ANSI color codes for compilation warnings/errors was recently > added to mach. If emacs users don't have ansi-mode turned on for > compilation buffers, they'll now see raw ANSI codes, which makes reading

Re: Removing navigator.buildID?

On Sat, Oct 29, 2016 at 7:21 AM, Kohei Yoshino wrote: > So the Battery Status API has just been removed, I think now is a good > time to think about navigator.buildID again, which bug [1] has been > inactive for a whole year. > > 4 years ago, Firefox 16 removed a minor

Re: Removal of B2G from mozilla-central

On Mon, Oct 3, 2016 at 3:20 PM, Gabriele Svelto wrote: > > Respectively, it seems like these requests were ultimately not included > > in the final decision. > > I would like to know why; I think that's not much to ask. I would also > like to know why this decision was made

Re: hg.mozilla.org certificate fingerprint changed?

`mach mercurial-setup` does an `hg pull` from hg.mozilla.org to obtain the version-control-tools repository, which is where most of the logic for `mach mercurial-setup` lives (because we have a nice testing harness in version-control-tools). `mach mercurial-setup` doesn't pin the hash when

Re: Upcoming hg.mozilla.org certificate change

c2716 < > https://treeherder.mozilla.org/#/jobs?repo=try=a83c34bc2716> > > -Justin > > > > On Sep 26, 2016, at 2:11 PM, Mats Palmgren <m...@mozilla.com> wrote: > > > > On 09/26/2016 07:20 PM, Gregory Szorc wrote: > >> # Mercurial 3.9+ > >> > >

Re: Upcoming hg.mozilla.org certificate change

age. On Thu, Sep 22, 2016 at 1:57 PM, Gregory Szorc <g...@mozilla.com> wrote: > hg.mozilla.org's x509 server certificate (AKA an "SSL certificate") > expires next week. > > A new certificate has already been issued and it is scheduled to be > swapped in around 2016

Re: Central Moving to Visual Studio 2015 Update 3

e time to upgrade so we don't disrupt people. On Tue, Sep 13, 2016 at 3:15 PM, Nicholas Nethercote <n.netherc...@gmail.com > wrote: > On Wed, Sep 14, 2016 at 3:22 AM, Gregory Szorc <g...@mozilla.com> wrote: > > Just landed on the autoland repo and making its way to central sh

Re: Build taskgraph generation landed

On Tue, Sep 13, 2016 at 1:02 PM, Dustin Mitchell wrote: > I think many of the concerned people were flagged for r? on bug > 1286075, but for everyone else, it's landed in inbound today. > > If you haven't mucked around with the configuration of which > TaskCluster tasks run

Central Moving to Visual Studio 2015 Update 3

Just landed on the autoland repo and making its way to central shortly is a transition of the Windows toolchain from Visual Studio 2015 Update 2 / Windows SDK 10.0.10586.0 to Visual Studio 2015 Update 3 w/ KB3165756 (version 14.0.25425.01) / Windows SDK 10.0.14393.0 (the Windows 10 Anniversary

Re: Intent to harden binary injection by removing XPCOM and related xul.dll exports

On Tue, Aug 30, 2016 at 8:44 AM, Benjamin Smedberg wrote: > This is notice of an intent to change how we export symbols from the > Firefox DLLs and binaries. > > Currently our policy is that extensions may not include binary XPCOM > components, and we've implemented some

Re: PSA: mozilla/unused.h renamed to mozilla/Unused.h

On Sat, Aug 27, 2016 at 7:22 PM, Tim Guan-tin Chien wrote: > Hi :gps, > > The more I read into this, the more I think the hook might not likely fix > things. The hook would reject rename-only commits, but the hook would > likely not reject a rename commit from |foo| to

Re: PSA: mozilla/unused.h renamed to mozilla/Unused.h

On Sat, Aug 27, 2016 at 9:00 AM, Eric Rescorla <e...@rtfm.com> wrote: > > On Sat, Aug 27, 2016 at 8:53 AM, Gregory Szorc <gsz...@mozilla.com> wrote: > >> >> >> > On Aug 27, 2016, at 07:09, Kan-Ru Chen <kc...@mozilla.com> wrote: >> > >

Re: PSA: mozilla/unused.h renamed to mozilla/Unused.h

> On Aug 27, 2016, at 07:09, Kan-Ru Chen <kc...@mozilla.com> wrote: > >> On Sat, Aug 27, 2016, at 11:35 AM, Gregory Szorc wrote: >>> On Fri, Aug 26, 2016 at 8:27 PM, Steve Fink <sf...@mozilla.com> wrote: >>> >>>> On 08/26/2016 08:16 PM,

Re: PSA: mozilla/unused.h renamed to mozilla/Unused.h

On Fri, Aug 26, 2016 at 8:27 PM, Steve Fink <sf...@mozilla.com> wrote: > On 08/26/2016 08:16 PM, Gregory Szorc wrote: > >> >> On Aug 26, 2016, at 19:54, Kan-Ru Chen <kc...@mozilla.com> wrote: >>> >>> Hello, >>> >>> In Bug 1297276 I

Re: PSA: mozilla/unused.h renamed to mozilla/Unused.h

> On Aug 26, 2016, at 19:54, Kan-Ru Chen wrote: > > Hello, > > In Bug 1297276 I landed a patch to rename mozilla/unused.h to > mozilla/Unused.h to make it more consistent with our other MFBT headers. > Normally rename a header shouldn't cause too much trouble, however this

Re: DXR: How to search for a file that has since been removed from the tree?

You can construct URLs like: https://hg.mozilla.org/mozilla-central/log/default/dom/canvas/WebGLContextReporter.cpp `hg log ` will also show the history of a known path ever under version control. The query should be very fast (even if the path disappeared hundreds of thousands of commits ago)

Re: Mercurial performance (vs git)

wrote: > This looks really great until I realized it did not print dirty state. > > There is probably no way to get the state without, say, `git status > --porcelain --u=no`, right? > > On Tue, Aug 16, 2016 at 4:09 AM, Gregory Szorc <g...@mozilla.com> wrote: > >> I use

Re: Rust 1.10 (to be) required to build Firefox with --enable-rust

On Wed, Aug 10, 2016 at 11:56 AM, Jared Wein <j...@mozilla.com> wrote: > On Wed, Aug 10, 2016 at 2:13 PM, Gregory Szorc <g...@mozilla.com> wrote: > >> On Wed, Aug 10, 2016 at 10:54 AM, Stefan Sitter <ssitter+n...@gmail.com> >> wrote: >> >

Re: Rust 1.10 (to be) required to build Firefox with --enable-rust

On Wed, Aug 10, 2016 at 10:54 AM, Stefan Sitter <ssitter+n...@gmail.com> wrote: > On 10.08.2016 17:28, Gregory Szorc wrote: > >> I'll be marking that bug wontfix as soon as I get in front of a >> computer with my BMO credentials. We plan to have no more releases of >

Re: Rust 1.10 (to be) required to build Firefox with --enable-rust

On Wed, Aug 10, 2016 at 10:46 AM, Ted Mielczarek <t...@mielczarek.org> wrote: > On Wed, Aug 10, 2016, at 11:28 AM, Gregory Szorc wrote: > > I'll be marking that bug wontfix as soon as I get in front of a computer > > with my BMO credentials. We plan to have no more release

Re: Rust 1.10 (to be) required to build Firefox with --enable-rust

I'll be marking that bug wontfix as soon as I get in front of a computer with my BMO credentials. We plan to have no more releases of MozillaBuild. There is support for installing Rust via rustup in 'mach bootstrap'. That requires an msys2 environment, which we should be rolling out soon. In

Re: Report your development frustrations via `mach rage`

e / tableflip / flame vocabulary when thinking about > what I want to do. Could we publicize this as "mach gripe", and leave > "rage" as an alias? > > On Mon, Aug 8, 2016 at 10:51 AM, Gregory Szorc <g...@mozilla.com> wrote: > >> Sometimes when hacking on Firef

Report your development frustrations via `mach rage`

Sometimes when hacking on Firefox/Gecko you experience something that irks you. But filing a bug isn't appropriate or could be time consuming. You instead vent frustrations on IRC, with others around the figurative water cooler, or - even worse - you don't tell anyone. The Developer Productivity

Re: Reproducible builds

On Sun, Jul 17, 2016 at 9:38 AM, David Bruant wrote: > Hi, > > Two recent comments on the Linux reproducible build bug thread [1] suggest > that the bug has no clear end goal. > > In this email, I'll try to describe what I understand of the problem and > discuss the outline

Re: Checkin-needed requests - Please include complete information in the commit message :)

On Fri, Jul 8, 2016 at 11:39 AM, Felipe G wrote: > Is there a way to make the checkin-needed flag generate a template comment > (like the approval-* ones do) with something like this? (Or encourage > people to use the per-patch checkin? flag) > > """ > Has this patch been

Re: Dropping support for VS2013

On Thu, Jun 30, 2016 at 5:55 PM, Gregory Szorc <g...@mozilla.com> wrote: > On Tue, May 31, 2016 at 4:22 PM, Gregory Szorc <g...@mozilla.com> wrote: > >> Heads up: we'll soon be dropping support for building mozilla-central >> with VS2013. Bug 1186064 tracks and th

Re: Faster gecko builds with IceCC on Mac and Linux

, especially to track > build system improvements (and regressions) as well as poorly-supported > configurations. > > Chris > > On Tue, Jul 5, 2016 at 7:42 PM, Gregory Szorc <g...@mozilla.com> wrote: > >> On Tue, Jul 5, 2016 at 3:58 PM, Ralph Giles <gi...@mozilla

Re: Faster gecko builds with IceCC on Mac and Linux

On Tue, Jul 5, 2016 at 3:58 PM, Ralph Giles <gi...@mozilla.com> wrote: > On Tue, Jul 5, 2016 at 3:36 PM, Gregory Szorc <g...@mozilla.com> wrote: > > > * `mach build binaries` (touch network/dns/DNS.cpp): 14.1s > > 24s here. So faster link times and significantly fa

Re: Faster gecko builds with IceCC on Mac and Linux

On Tue, Jul 5, 2016 at 2:37 PM, Ralph Giles <gi...@mozilla.com> wrote: > On Tue, Jul 5, 2016 at 12:12 PM, Gregory Szorc <g...@mozilla.com> wrote: > > > I recommend 2x Xeon E5-2637v4 or E5-2643v4. > > For comparison's sake, what kind of routine and clobber build

Re: Faster gecko builds with IceCC on Mac and Linux

On Tue, Jul 5, 2016 at 2:27 PM, Chris Pearce wrote: > It would be cool if, once distributed compilation is reliable, if `./mach > mercurial-setup` could 1. prompt you enable using the local network's > infrastructure for compilation, and 2. prompt you to enable sharing your

Re: Faster gecko builds with IceCC on Mac and Linux

mployees to have fast machines. FWIW, Mozilla has been known to send community contributors hardware so they can have a better development experience. Send an email to mh...@mozilla.com to inquire. > > On 2016/07/06 4:12, Gregory Szorc wrote: > > On Tue, Jul 5, 2016 at 11:08 AM, Steve

Re: Faster gecko builds with IceCC on Mac and Linux

On Tue, Jul 5, 2016 at 7:07 AM, Michael Layzell wrote: > I'm certain it's possible to get a windows build working, the problem is > that: > > a) We would need to modify the client to understand cl-style flags (I don't > think it does right now) > b) We would need to

Re: The integration/autoland repo

On Tue, Jun 28, 2016 at 11:44 AM, Gregory Szorc <g...@mozilla.com> wrote: > As of a few minutes ago, when you land commits from MozReview they will be > pushed to https://hg.mozilla.org/integration/autoland instead of > https://hg.mozilla.org/integration/mozilla-inbound. >

Re: Dropping support for VS2013

On Tue, May 31, 2016 at 4:22 PM, Gregory Szorc <g...@mozilla.com> wrote: > Heads up: we'll soon be dropping support for building mozilla-central with > VS2013. Bug 1186064 tracks and the patch has already received r+. > > I'm going to wait a few days before landing

PSA: Windows Defender can slow down builds and tests

I recently started using Windows as my main development environment (because that's what most Firefox users use and I want to improve the Firefox development experience on Windows so more people develop on Windows). It seems every day I find another source of painful slowdowns and productivity

Re: MXR permanently offline, please transition to DXR

On Thu, Jun 30, 2016 at 4:55 PM, Robert O'Callahan wrote: > > In theory responses 301 and 308 mean "permanent redirect" so the browser > could do that for those responses. > > In practice you'd need a lot of data to convince yourself that Web > developers haven't screwed

Re: MXR permanently offline, please transition to DXR

On Thu, Jun 30, 2016 at 7:20 AM, Dão Gottwald wrote: > Can we please automatically redirect from > https://mxr.mozilla.org/mozilla-central/source/x/y.z to > https://dxr.mozilla.org/mozilla-central/source/x/y.z? My browsing history > is littered with mxr URLs which used to

The integration/autoland repo

As of a few minutes ago, when you land commits from MozReview they will be pushed to https://hg.mozilla.org/integration/autoland instead of https://hg.mozilla.org/integration/mozilla-inbound. For now, think of integration/autoland as just another mozilla-inbound or fx-team. In fact, the sheriffs

Rewritten `mach mercurial-setup` / Mercurial slides from London

As of a few weeks ago, `mach mercurial-setup` and its integration with mach have been rewritten. The Mercurial configuration wizard has been rewritten and contains a number of new features. If you haven't executed `mach mercurial-setup` lately, I encourage you to do so to ensure you have the

Re: One Firefox repository to rule them all

On Mon, Jun 27, 2016 at 3:36 PM, Mike Hommey <m...@glandium.org> wrote: > On Mon, Jun 27, 2016 at 02:23:52PM -0700, Gregory Szorc wrote: > > The unified Firefox repo has now been moved out of experimental status > and > > is available at https://hg.mozilla.org/mo

Re: Searchfox (new code search tool)

On Mon, Jun 6, 2016 at 9:35 PM, Bill McCloskey wrote: > Hi everyone, > > I would like to announce a new tool I've been working on for source > code searching called Searchfox (http://searchfox.org). If you use MXR > or DXR, I recommend you try Searchfox. Here are some of

Re: Generating Visual Studio project files by default

On Thu, Jun 2, 2016 at 9:47 PM, Jean-Yves Avenard <jyaven...@gmail.com> wrote: > On Wednesday, May 25, 2016 at 9:00:48 AM UTC+10, Gregory Szorc wrote: > > This change was tracked in bug 1275297. Bug 1275419 tracks a follow-up to > > allow disabling their generation. > &g

Dropping support for VS2013

Heads up: we'll soon be dropping support for building mozilla-central with VS2013. Bug 1186064 tracks and the patch has already received r+. I'm going to wait a few days before landing because this could be disruptive and I want to at least give a heads up before I create a fire. Please install

Re: Generating Visual Studio project files by default

to make this work the way you want it to. Please file a bug and CC gps and Nat. > > Does it supports nmake as well? > No. It effectively shells out to `mach build` for the heavy lifting. > > Thanks. > > Wei-Cheng Pan > > On 5/25/16 7:00 AM, Gregory Szorc wrote: &g

Re: Generating Visual Studio project files by default

I've been doing a lot of work lately to surface and monitor this data better. If you feel this change has a noticeable negative impact on a particular workflow because of the overhead, please file a bug. > >> On Tue, May 24, 2016 at 4:00 PM, Gregory Szorc <g...@mozilla.com> wrote

Generating Visual Studio project files by default

Coming soon to your local builds, Visual Studio project files will be generated automatically when building on Windows because we want to encourage more people to use them because fully-featured IDEs can be productivity wins. The Visual Studio projects now automatically target the Visual Studio

Re: Tier-1 for Linux 64 Debug builds in TaskCluster on March 14 (and more!)

On Thu, May 19, 2016 at 4:24 PM, Xidorn Quan wrote: > On Fri, May 20, 2016 at 8:16 AM, Selena Deckelmann > wrote: > > > Closing out this thread - we made Linux 64 Debug builds Tier 1 mid-April, > > and last week we turned off the related buildbot jobs.

Re: Two talos jobs for PGO builds on fx-team and m-i

What impact will this have on machine capacity? The Windows and Mac testers are already highly overwhelmed. Try jobs are often delayed by several hours, which I think is a major concern. (I can't remember if we have a separate pool for Talos testers [on Try].) > On May 12, 2016, at 05:01,

Re: Reverting to VS2013 on central and aurora

On Thu, May 5, 2016 at 9:26 PM, Gregory Szorc <g...@mozilla.com> wrote: > There is a compiler bug in VS2015 that results in SSE instructions being > emitted when they shouldn't be. Since Firefox still needs to remain > compatible with ancient hardware that doesn't support SSE,

Re: Reverting to VS2013 on central and aurora

toolchains would be on central, as that is where most developers and automation live. > > On Fri, May 6, 2016 at 10:10 AM, Mike Hoye <mh...@mozilla.com> wrote: > >> On 2016-05-06 12:26 AM, Gregory Szorc wrote: >> >>> FWIW, the crashes we've seen so far are from

Re: Reverting to VS2013 on central and aurora

On Fri, May 6, 2016 at 7:10 AM, Mike Hoye <mh...@mozilla.com> wrote: > On 2016-05-06 12:26 AM, Gregory Szorc wrote: > >> FWIW, the crashes we've seen so far are from incorrectly emitted movss >> instructions. This instruction is part of the original SSE instruction >&g

Reverting to VS2013 on central and aurora

There is a compiler bug in VS2015 that results in SSE instructions being emitted when they shouldn't be. Since Firefox still needs to remain compatible with ancient hardware that doesn't support SSE, this is causing crashes on Firefox built with VS2015 (see bug 1265615). The good news is glandium

Re: Intent to deprecate: MacOS 10.6-10.8 support

On Tue, May 3, 2016 at 3:53 PM, Chris Peterson wrote: > On 5/3/16 3:11 AM, Xidorn Quan wrote: > >> > Then we should plan to drop Universal builds in the same release, >>> > because without supporting 10.6 or 32-bit NPAPI plugins, the 32-bit >>> half >>> > of the build is

Re: Intent to deprecate: MacOS 10.6-10.8 support

On Mon, May 2, 2016 at 4:10 PM, Gregory Szorc <g...@mozilla.com> wrote: > On Mon, May 2, 2016 at 3:51 PM, Lawrence Mandel <lman...@mozilla.com> > wrote: > >> On Mon, May 2, 2016 at 2:28 PM, Ralph Giles <gi...@mozilla.com> wrote: >> >> > On Fri

Re: Intent to deprecate: MacOS 10.6-10.8 support

On Mon, May 2, 2016 at 4:10 PM, Gregory Szorc <g...@mozilla.com> wrote: > On Mon, May 2, 2016 at 3:51 PM, Lawrence Mandel <lman...@mozilla.com> > wrote: > >> On Mon, May 2, 2016 at 2:28 PM, Ralph Giles <gi...@mozilla.com> wrote: >> >> > On Fri

Re: One Firefox repository to rule them all

15 minutes ago to get this new feature. > > > > > On 14/04/16 08:22 PM, Gregory Szorc wrote: > >> I'm pleased to announce the immediate availability of some *experimental* >> read-only Mercurial repositories containing the combined, useful history >> of >&

Re: Intent to deprecate: MacOS 10.6-10.8 support

On Mon, May 2, 2016 at 3:51 PM, Lawrence Mandel wrote: > On Mon, May 2, 2016 at 2:28 PM, Ralph Giles wrote: > > > On Fri, Apr 29, 2016 at 9:52 PM, Lawrence Mandel > > wrote: > > > > > I had planned to update the thread after the post

Re: Intent to ship: Speech synthesis API

On Thu, Apr 28, 2016 at 12:52 PM, Eitan Isaacson wrote: > Hello, > > In Firefox 49 I intend to turn on the speech synthesis API on by default in > desktop. > > For those paying close attention, this is not the first mail like this. > Last time I turned it on in Nightly

Re: Build System Project - Update from the last 2 weeks

> On Apr 20, 2016, at 08:16, Nicolas B. Pierron > wrote: > > Unrelated, Do we have news for clang blockers on Windows? In particular, I > am thinking about the various Sanitizers. We haven't really talked about Clang on Windows in our build meeting/plannings.

Re: One Firefox repository to rule them all

unified repo yet, but we could. Let's hash something out in bug 1264814. > > > > > On 14/04/16 08:22 PM, Gregory Szorc wrote: > >> I'm pleased to announce the immediate availability of some *experimental* >> read-only Mercurial repositories containing the combined, us

Re: One Firefox repository to rule them all

On Thu, Apr 14, 2016 at 6:45 PM, Dave Townsend <dtowns...@mozilla.com> wrote: > On Thu, Apr 14, 2016 at 5:22 PM, Gregory Szorc <g...@mozilla.com> wrote: > >> I'm pleased to announce the immediate availability of some *experimental* >> read-only Mercurial reposi

Re: One Firefox repository to rule them all

On Thu, Apr 14, 2016 at 9:34 PM, wrote: > When will mozilla-central use generaldelta? > It's complicated. But https://hg.mozilla.org/experimental/mozilla-central-gd exists now. It is ~400 MB smaller than mozilla-central. I also filed bug 1265075 to track advertising a

One Firefox repository to rule them all

I'm pleased to announce the immediate availability of some *experimental* read-only Mercurial repositories containing the combined, useful history of the various Firefox repositories, all in chronological order and stored in a more efficient format that is faster to clone and pull from and results

Re: Why is Mozreview hassling me about squashed commits?

On Sat, Apr 2, 2016 at 5:51 PM, Eric Rescorla <e...@rtfm.com> wrote: > On Sat, Apr 2, 2016 at 5:59 PM, Gregory Szorc <g...@mozilla.com> wrote: > >> When you say "I almost never want to review individual commits and >> instead want to review the changeset as a si

Re: Why is Mozreview hassling me about squashed commits?

> On Apr 4, 2016, at 10:33, Ted Mielczarek wrote: > >> On Mon, Apr 4, 2016, at 12:46 PM, Steve Fink wrote: >> I should clarify that by "non-mq", I really mean using mutable-history >> aka evolve. And yes, my workflow does depend on some extensions, >> including some

Re: Why is Mozreview hassling me about squashed commits?

> On Apr 3, 2016, at 18:09, L. David Baron wrote: > >> On Saturday 2016-04-02 18:51 -0300, Eric Rescorla wrote: >> 1. I write a bunch of code, committing along the way, so I have a lot of >> commits named "Checkpoint" and "Fix bug" and the like. >> 2. When it works, I push

Re: Upcoming SSH Host Key Rotation for hg.mozilla.org

e adopting these "modern" SSH server settings. So you'll have to upgrade sometime. On Mon, Apr 4, 2016 at 8:36 AM, Gregory Szorc <g...@mozilla.com> wrote: > This change was just made (we delayed because we didn't want to take > extra risks on a Friday afternoon). > > A GPG sign

Re: Upcoming SSH Host Key Rotation for hg.mozilla.org

This change was just made (we delayed because we didn't want to take extra risks on a Friday afternoon). A GPG signed document detailing the current keys is available at https://hg.mozilla.org/hgcustom/version-control-tools/raw-file/tip/docs/vcs-server-info.asc On 3/31/16 2:39 PM, Gregory Szorc

Re: Why is Mozreview hassling me about squashed commits?

When you say "I almost never want to review individual commits and instead want to review the changeset as a single diff," I'm confused because a commit is a changeset (in Mercurial terms at least) and this statement is contradictory. You seem to be saying that you want to look at a series of

Upcoming SSH Host Key Rotation for hg.mozilla.org

This message serves as a notice that the *SSH host keys* for hg.mozilla.org will be rotated in the next ~24 hours. When connecting to hg.mozilla.org over SSH, your SSH client should warn that host keys have changed and refuse to connect until accepting/trusting the new host key. After 1st host

Re: Intent to switch to Visual Studio 2015

> On Mar 24, 2016, at 23:25, Xidorn Quan <quanxunz...@gmail.com> wrote: > >> On Fri, Mar 25, 2016 at 12:44 AM, Gregory Szorc <g...@mozilla.com> wrote: >> On Wed, Mar 23, 2016 at 7:03 PM, Gregory Szorc <g...@mozilla.com> wrote: >> >> >

Re: Intent to switch to Visual Studio 2015

On Wed, Mar 23, 2016 at 7:03 PM, Gregory Szorc <g...@mozilla.com> wrote: > On Wed, Mar 16, 2016 at 11:49 PM, Gregory Szorc <g...@mozilla.com> wrote: > >> >> On Thu, Mar 10, 2016 at 8:14 AM, Gregory Szorc <g...@mozilla.com> wrote: >> >>> Visua

Re: Intent to switch to Visual Studio 2015

On Wed, Mar 16, 2016 at 11:49 PM, Gregory Szorc <g...@mozilla.com> wrote: > > On Thu, Mar 10, 2016 at 8:14 AM, Gregory Szorc <g...@mozilla.com> wrote: > >> Visual Studio 2015 has been out for a while. Many people have put in >> work to make Firefox build on it

Re: JS Shell Disabled by Default in Browser Builds

On Wed, Mar 23, 2016 at 3:20 PM, Steve Fink <sf...@mozilla.com> wrote: > On 03/23/2016 02:22 PM, Gregory Szorc wrote: > >> Bug 1254873 changed the default behavior of configure to not build the JS >> shell by default for non-standalone JS builds. The reasons are outlined

JS Shell Disabled by Default in Browser Builds

Bug 1254873 changed the default behavior of configure to not build the JS shell by default for non-standalone JS builds. The reasons are outlined in bug 1251324. tl;dr compiling the JS shell takes a non-significant amount of time for a feature that we believe most don't use. To continue building

Re: Intent to switch to Visual Studio 2015

On Thu, Mar 17, 2016 at 3:30 PM, wrote: > What about the depreciation of XP SP2? > Results from bug 1124017 say XP SP2 still works on binaries built with VS2015u1. This may not always hold true. So we will need to have the XP SP2 discussion at some point. I defer to

Re: Intent to switch to Visual Studio 2015

On Thu, Mar 10, 2016 at 8:14 AM, Gregory Szorc <g...@mozilla.com> wrote: > Visual Studio 2015 has been out for a while. Many people have put in work > to make Firefox build on it. The time has come to officially transition > release builds from Visual Studio 2013 to Vis

Re: Intent to switch to Visual Studio 2015

On Thu, Mar 10, 2016 at 10:29 AM, Aaron Klotz <akl...@mozilla.com> wrote: > I'm looking forward to this! > > On 3/10/2016 9:14 AM, Gregory Szorc wrote: > >> >> A host of new C++ features should be available after the switch. Although, >> we may have to drop

Intent to switch to Visual Studio 2015

Visual Studio 2015 has been out for a while. Many people have put in work to make Firefox build on it. The time has come to officially transition release builds from Visual Studio 2013 to Visual Studio 2015. This email serves as an intent to switch automation to Visual Studio 2015 Update 1

Re: Submit to MozReview using Git

I filed bug 1254249 to track improving this. It isn't high on my priority list though, so if someone wants to take it, I'll happily review the patch! On Wed, Mar 2, 2016 at 8:24 PM, Tim Guan-tin Chien wrote: > Thanks for the pointer! I ended up re-do the cloning from hg

Re: Proposing preferring Clang over GCC for developer buidls

ormed about future version compatibility and can report regressions upstream. It turns out compiling Firefox is a pretty good test suite! > > > On Mar 2, 2016, at 17:50 , Gregory Szorc <g...@mozilla.com> wrote: > > > > switching

Re: Proposing preferring Clang over GCC for developer buidls

che, that may make GCC faster than Clang in automation. Need moar data. > > On Wed, Mar 2, 2016 at 2:50 PM, Gregory Szorc <g...@mozilla.com> wrote: > > Over in bug 1253064 I'm proposing switching developer builds to prefer > > Clang over GCC because the limited numbers we hav

Proposing preferring Clang over GCC for developer buidls

Over in bug 1253064 I'm proposing switching developer builds to prefer Clang over GCC because the limited numbers we have say that Clang can build mozilla-central several minutes faster than GCC (13 minutes vs 17.5 on my I7-6700K). I'm not proposing switching what we use to produce builds in

Generic Task Cluster Tasks / File Based Task Scheduling

Over in bug 1245953 I implemented some new features for in-tree Task Cluster tasks: * You can now define tasks that are neither "build" nor "test" tasks. This mechanism is probably where you should place one-off tasks such as linting, docs generation, code analysis, etc. See

Re: MozReview/Autoland in degraded state

fter that if there are unresolvable issues. You can follow along > > in #mozreview. > > > > Other fixes to LDAP and Autoland will follow Mondayish. > > > > Thank you for your patience. > > > > Mark > > > > > > On 2016-02-03 3:02 AM, Gregory Szor

Submit to MozReview using Git

It is now possible to submit reviews to MozReview using Git. Instructions are at https://mozilla-version-control-tools.readthedocs.org/en/latest/mozreview/install-git.html Bugs should be filed against Developer Services :: MozReview. #mozreview is your support IRC channel.

Re: PSA: Please stop revving UUIDs when changing XPIDL interface

On Fri, Jan 29, 2016 at 1:52 PM, Ehsan Akhgari wrote: > (Sending this in another thread in case people didn't see my note at the > end of the original thread.) > > The new rules are in effect for mozilla-central and the repositories that > merge into it. Revving UUIDs

Re: Just Autoland It

I'd like to thank everyone for the feedback in this thread. However, the thread has grown quite long and has detoured from its original subject. Speaking on behalf of everyone who works on MozReview, we know the interface is lacking in areas and features are confusing or non-existent. We're

Re: Just Autoland It

On Fri, Jan 22, 2016 at 1:45 PM, Boris Zbarsky <bzbar...@mit.edu> wrote: > On 1/22/16 3:52 PM, Gregory Szorc wrote: > >> I would say that pushing cherry-picked commits for review that depend on >> other commits not in the commit's ancestry is just wrong. If you pushed

Re: Just Autoland It

nsend <dtowns...@mozilla.com> > wrote: > >> Should we just add a "and land it" checkbox to the review page, maybe >> disabled if there are still open issues? >> >> On Thu, Jan 21, 2016 at 6:35 PM, Gregory Szorc <g...@mozilla.com> wrote: >> > If y

Re: Just Autoland It

On Sat, Jan 23, 2016 at 6:39 AM, Gijs Kruitbosch <gijskruitbo...@gmail.com> wrote: > On 22/01/2016 20:52, Gregory Szorc wrote: > >> I would say that pushing cherry-picked commits for review that depend on >> other commits not in the commit's ancestry is just wrong. If y

Re: Just Autoland It

On Sat, Jan 23, 2016 at 4:01 PM, Eric Rescorla <e...@rtfm.com> wrote: > > > On Sat, Jan 23, 2016 at 10:20 AM, Gregory Szorc <g...@mozilla.com> wrote: > >> On Fri, Jan 22, 2016 at 1:45 PM, Boris Zbarsky <bzbar...@mit.edu> wrote: >> >> > On 1/22/

Re: Just Autoland It

On Fri, Jan 22, 2016 at 11:24 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com> wrote: > On 2016-01-22 2:10 PM, Gregory Szorc wrote: > >> On Fri, Jan 22, 2016 at 7:30 AM, Boris Zbarsky <bzbar...@mit.edu> wrote: >> >> On 1/22/16 10:08 AM, Andrew Halbers

Re: Just Autoland It

On Fri, Jan 22, 2016 at 7:30 AM, Boris Zbarsky wrote: > On 1/22/16 10:08 AM, Andrew Halberstadt wrote: > >> In the end, it's on the reviewer. If the patch is complicated, has open >> dependencies or looks like it might cause problems, as a reviewer I'm >> not going to land it

<    1   2   3   4   5   6   >