Re: Just Autoland It

window at our meeting today and this is definitely one of the improvements we want to make. Look for significant changes to this UI in the weeks ahead. > >> On Thu, Jan 21, 2016 at 6:35 PM, Gregory Szorc <g...@mozilla.com> wrote: >> If you have level 3 source code access (can push

Just Autoland It

If you have level 3 source code access (can push to central, inbound, fx-team) and have pushed to MozReview via SSH, as of a few weeks ago you can now land commits from the "Automation" drop down menu on MozReview. (Before only the review request author could trigger autoland.) This means that

Re: Just Autoland It

ete faster before we can do this, as I'm sure a lot of people would not appreciate an extra few hours of delay between initiating landing and it making it through Try to the final landing repository. I don't know if we'll get there in 2016. > > On 22/01/16 03:35, Gregory Szorc wrote: > &

Re: Just Autoland It

On Jan 21, 2016, at 21:25, Richard Newman wrote: >> Both of these behaviours are incompatible with reviewer-initiated landing. > > I've fallen on both sides of this particular fence; sometimes I want to > fire-and-forget a patch, and sometimes I still want to digest

Re: Just Autoland It

> On Jan 21, 2016, at 21:46, Mike Hommey <m...@glandium.org> wrote: > >> On Thu, Jan 21, 2016 at 06:35:08PM -0800, Gregory Szorc wrote: >> If you have level 3 source code access (can push to central, inbound, >> fx-team) and have pushed to MozReview via SSH, as of

Re: Just Autoland It

On Thu, Jan 21, 2016 at 10:37 PM, Mike Connor wrote: > Like Greg, I'm a big fan of reviewer-lands-if-ready. It's a huge > simplification of workflow, saves developers time, and lets machines do > work instead of humans. That said, I don't think we should be surprising >

Re: Rust as build requirement was Re: Proposal to a) rewrite Gecko's encoding converters and b) to do it in Rust

On Mon, Dec 14, 2015 at 6:58 PM, Cameron Kaiser wrote: > Replying to a couple messages at once. > > On 12/14/15 2:19 PM, Mike Hoye wrote: > >> On 2015-12-14 4:06 PM, Justin Dolske wrote: >> >>> On 12/14/15 2:51 AM, Ted Mielczarek wrote: >>> >>> [...]Obviously this isn't

Improving blame in Mercurial

As Mitchell announced the other night, Mercurial is being awarded a MOSS grant to improve its blame/annotate functionality. Blame has been cited by a number of Mozillians as something that they would love to see improved and the MOSS grant provides the Mercurial Project the means to make it

Re: Faster Windows builds everywhere!

On Tue, Dec 1, 2015 at 2:21 PM, Chris AtLee wrote: > Right now we've got debug OSX builds in the cloud on Try in parallel with > the regular builds. There's a bunch more work to be done there to be able > to switch over, but we're definitely making progress. > > All Windows /

Re: Announcing MozillaBuild 2.1.0 Release

On Tue, Nov 24, 2015 at 9:56 AM, Ryan VanderMeulen < rvandermeu...@mozilla.com> wrote: > I am pleased to announce the final release of MozillaBuild 2.1.0. All users > are encouraged to upgrade as soon as possible due to many improvements in > Mercurial since the last release. > >

Re: Merging comm-central into mozilla-central

On Fri, Nov 6, 2015 at 1:46 PM, Mike Hommey wrote: > On Fri, Nov 06, 2015 at 01:12:30PM -0600, Joshua Cranmer ? wrote: > > On 11/6/2015 12:38 PM, Doug Turner wrote: > > >I would have rather done this in a private email, but some replied and > said I wasn’t clear. > > > > > > >

Re: Merging comm-central into mozilla-central

On Fri, Oct 23, 2015 at 6:22 PM, Benjamin Smedberg wrote: > I support going back to a giant monolithic repository if we can cleanly > delineate the code for various projects. > > We know that the searchability and readability of our code is a major > barrier to some kinds

Re: Merging comm-central into mozilla-central

On Fri, Oct 23, 2015 at 11:39 PM, Jonas Sicking <jo...@sicking.cc> wrote: > On Fri, Oct 23, 2015 at 3:11 PM, Gregory Szorc <g...@mozilla.com> wrote: > > > > We'll be investing pretty heavily in the Firefox build system in 2016. I > > cannot stress enough

Re: Merging comm-central into mozilla-central

On Fri, Oct 23, 2015 at 11:13 PM, Eric Rescorla <e...@rtfm.com> wrote: > > > On Fri, Oct 23, 2015 at 3:11 PM, Gregory Szorc <g...@mozilla.com> wrote: > >> On Fri, Oct 23, 2015 at 10:08 PM, Mike Hommey <m...@glandium.org> wrote: >> >> > On Fri,

Re: Merging comm-central into mozilla-central

On Fri, Oct 23, 2015 at 10:08 PM, Mike Hommey wrote: > On Fri, Oct 23, 2015 at 01:22:35PM -0400, Benjamin Smedberg wrote: > > I support going back to a giant monolithic repository if we can cleanly > > delineate the code for various projects. > > > > We know that the

Re: Merging comm-central into mozilla-central

On Fri, Oct 23, 2015 at 8:57 AM, Mike Hommey wrote: > Hi, > > This has been discussed in the past, to no avail. I would like to reopen > the discussion. > > Acknowledgment: this is heavily inspired from a list compiled by Joshua > Cranmer, but please consider this *also*

Re: Changes to third-party access for Mozilla organizations on GitHub

This transition was performed ~90 minutes ago. Re-enabling applications is still in progress. Now would be a good time to audit your applications, services, hooks, SSH keys, etc. Join #github on irc.mozilla.org or email github-own...@mozilla.org if you have any questions or need help. On Fri,

Re: Intent to unship: jar: URIs from content

On Sat, Oct 17, 2015 at 3:48 PM, Ben Kelly wrote: > On Oct 16, 2015 6:17 PM, "Robert O'Callahan" wrote: > > I guess the right fix would be to have a Web proxy service that accepts > > URLs in a custom format, unpacks ZIP files and serves their contents.

Re: Decommissioning "dumbmake"

On Mon, Oct 19, 2015 at 11:47 AM, Bobby Holley wrote: > On Mon, Oct 19, 2015 at 8:20 AM, Josh Matthews > wrote: > > > On 2015-10-19 1:17 AM, Bobby Holley wrote: > > > >> I've heard two compelling arguments against the current setup: > >> (1) It's

Re: Decommissioning "dumbmake"

On Thu, Oct 15, 2015 at 6:37 PM, Nicholas Nethercote wrote: > On Fri, Oct 16, 2015 at 11:37 AM, Bobby Holley > wrote: > > > > |mach build binaries| is much slower for me than the present behavior, > > because I often hack on header files that are

Re: Intent to unship: jar: URIs from content

On Thu, Oct 15, 2015 at 4:08 PM, Robert O'Callahan wrote: > I'm sad that I won't be able to use jar: URLs to load testcases in ZIP > files uploaded to Bugzilla, but this sounds like the right thing to do. > If this is a common use case, then `mach test` should be able to

Re: PSA: Local static analysis builds on Linux and Mac OS X

On Wed, Oct 14, 2015 at 6:07 PM, Ehsan Akhgari wrote: > Last weekend, I finished upgrading our Linux and OS X debug and opt static > analysis builds ("S" jobs on TreeHerder) to the latest revision of clang > 3.7. > > Now, if you use the latest version of clang (3.7,

Re: Building js/xul/css from Firefox faster

Basically a set of build actions related to frontend development and known by moz.build files are assembled in a single make file that contains a single DAG and doesn't need to recurse into directories. See python/mozbuild/mozbuild/backend/fastermake.py and /faster/Makefile for the low-level

Re: Disabling C++ tests by default?

On Thu, Oct 1, 2015 at 10:12 PM, Kyle Huey wrote: > How much time does it save? > On my MBP, removing all CPP_UNIT_TESTS from moz.builds (which also stops the production of a few static libraries): -141s CPU time (6831s total, so 2%) -16s wall time `mach build binaries`

Re: Disabling C++ tests by default?

On Fri, Oct 2, 2015 at 1:40 PM, Bobby Holley wrote: > On Fri, Oct 2, 2015 at 1:03 PM, Ehsan Akhgari > wrote: > >> On 2015-10-02 2:42 PM, Jonas Sicking wrote: >> >>> It might still mean that we can save time on tryserver if we only >>> build these

Disabling C++ tests by default?

Currently, the Firefox build system builds C++ tests by default. This adds extra time to builds for something that a significant chunk of developers don't care about because they don't run them. An easy way to get faster builds is to disable C++ tests by default (requiring a mozconfig entry to

Re: About static analyzers on some various projects

On Sun, Sep 27, 2015 at 10:54 AM, Ehsan Akhgari wrote: > On 2015-09-25 7:35 PM, Robert O'Callahan wrote: > >> On Sat, Sep 26, 2015 at 7:34 AM, Ehsan Akhgari > > wrote: >> >> On 2015-09-25 12:01 PM, Justin

Re: About static analyzers on some various projects

On Fri, Sep 25, 2015 at 12:19 AM, Robert O'Callahan wrote: > On Fri, Sep 25, 2015 at 5:41 AM, Sylvestre Ledru > wrote: > > > Any questions, comments? > > > > This whitepaper on Infer is an interesting read: > >

Re: |hg bzexport| and Bugzilla two-factor authentication

I am pretty sure this is due to running hg from a py2exe based Mercurial distribution on Windows. This is pretty much any hg on Windows that isn't MozillaBuild 2.0. This includes TortoiseHg. Things have or will break unless running MozillaBuild 2.0. Please file a Developer Services product bug

Re: Alternative to Bonsai?

On Wed, Sep 16, 2015 at 10:22 AM, Boris Zbarsky wrote: > On 9/16/15 2:38 AM, Philip Chee wrote: > >> But we don't have a working CVS repository any more right? >> > > I could be confused, but I believe the CVS repo exists. It can certainly > be used in a read-only mode. I

Re: Alternative to Bonsai?

On Tue, Sep 15, 2015 at 8:08 AM, Philip Chee wrote: > The Bonsai server +infra is gone. Is there an alternative? > > Is there a mercurial repository that has a unified history of > mozilla-central plus cvs history? Bonus if it also includes comm-central. >

Re: mach mozregression command

On Mon, Sep 14, 2015 at 11:01 AM, William Lachance wrote: > On 2015-09-14 1:17 PM, Benjamin Smedberg wrote: > >> Does this command work by downloading nightly/hourly builds (the way >> mozregression typically works) or by doing local builds at various >> changesets and

Re: Linux builds now default to building with Gtk+3

https://hg.mozilla.org/mozilla-central/rev/05f6b5bc5b4b should have done this. Please file a follow-up if your tree is up to date and things aren't working. On Mon, Aug 10, 2015 at 10:12 AM, Dave Townsend dtowns...@mozilla.com wrote: Can we update the bootstrap script to install the necessary

Re: Can we make a plan to retire Universal Mac builds?

On Aug 5, 2015, at 08:12, Ted Mielczarek t...@mielczarek.org 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

Re: XULRunner future and ownership

On Wed, Jul 29, 2015 at 1:07 PM, Fabrice Desré fabr...@mozilla.com wrote: On Wed, 29 Jul 2015 14:30:00 -0400, Benjamin Smedberg wrote: If I do not find a suitable owner in the next two weeks, I intend to remove the XULRunner code from the mozilla-central repository on 14-August. Two

Re: Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)

The public source code for Firefox has existed for 17+ years (since ~April 1998). We can only assume it will be around for another 10+ years. I believe you have to take the long view on the cost benefit analysis and realize that a lot of pain in the short term (e.g. switching styles entirely)

Re: Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)

On Tue, Jul 14, 2015 at 9:06 AM, David Major dma...@mozilla.com wrote: May I request that the major parts of this not happen until we have a blame that can see through such changes. Last I checked, gps had some ideas in that space but lacked time to implement. I spoke to a Mercurial

Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++

On Tue, Jul 7, 2015 at 1:03 PM, smaug sm...@welho.com wrote: As someone who spends more than 50% of working time doing reviews I'm strongly against this proposal. aFoo helps with readability - reader knows immediately when the code is dealing with arguments. I'd like to point out that

Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++

On Tue, Jul 7, 2015 at 5:13 PM, Jeff Gilbert jgilb...@mozilla.com wrote: On Tue, Jul 7, 2015 at 3:59 PM, Eric Rahm er...@mozilla.com wrote: I'm not a huge fan of the 'aFoo' style, but I am a huge fan of consistency. So if we want to change the style guide we should update our codebase,

Re: How create a full copy of mozbuild and dependencies at https://github.com/html-shell/mozbuild

The mozbuild Python package is available on PyPI: https://pypi.python.org/pypi/mozbuild It's also possible to obtain an archive of the source from hg.mozilla.org. See the instructions for the archive command/URL at https://hg.mozilla.org/mozilla-central/help/hgweb. I would strongly prefer to not

Re: Disabling the startup cache

On Jun 20, 2015, at 20:55, Mike Hommey m...@glandium.org wrote: On Sat, Jun 20, 2015 at 02:36:26PM -0600, Aaron Klotz wrote: On 6/20/2015 10:20 AM, Philip Chee wrote: Anyone want to try the same with Firefox nightly? Already did it and subsequently filed bug 873638. We can do it if we

Re: Mercurial with bash prompt

Install hgwatchman to make status fast. It runs the watchman file system watching tool so Mercurial barely has to talk to the file system when doing status, diff, commit, and similar operations. This profile doesn't show it, but incoming and outgoing usually require network I/O to discover

Re: Mercurial with bash prompt

I have the following: hg_ps1() { hg prompt {({bookmark})} 2 /dev/null } export PS1='... $(hg_ps1)\$ ' I do not get multiple second latency. You should capture --profile output from your prompt command and see what's taking so long. File a Mozilla bug against Developer Services ::

Re: Revisiting modelines in source files

On Fri, Jun 19, 2015 at 6:45 AM, Birunthan Mohanathas birunt...@mohanathas.com wrote: Hi, Over the past year, I have converted a few directories (xpcom/, docshell/, embedding/) to Gecko style using a patched Clang-Format and a few other tools. On 17 June 2015 at 18:57, Gregory Szorc g

Re: Revisiting modelines in source files

On Wed, Jun 17, 2015 at 6:29 PM, Robert O'Callahan rob...@ocallahan.org wrote: As an experiment, we declared the coding style of rr to be whatever clang-format produces with rr's .clang-format file (which was tweaked to resemble Mozilla style, including an 80-char line limit). Overall I've

Re: Revisiting modelines in source files

On Wed, Jun 17, 2015 at 8:14 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2015-06-17 11:04 AM, Mike Hoye wrote: On 2015-06-17 6:53 AM, Mike Hommey wrote: So how about removing modelines and adding editorconfig files? I understand we're considering (or getting close to?)

Extra commit metadata on hg.mozilla.org

hg.mozilla.org now displays extra metadata on changeset pages. e.g. https://hg.mozilla.org/mozilla-central/rev/dc4023d54436. Read more at http://gregoryszorc.com/blog/2015/06/04/changeset-metadata-on-hg.mozilla.org/ If you notice anything wonky, including performance issues, please speak up. I'm

Re: Replacing PR_LOG levels

On Fri, May 22, 2015 at 12:22 PM, Bobby Holley bobbyhol...@gmail.com wrote: On Fri, May 22, 2015 at 12:11 PM, Gregory Szorc g...@mozilla.com wrote: Better than a log level is an event type (possibly enumerated). When people are looking at log output, they want to see specific events. While

Re: Replacing PR_LOG levels

On Thu, May 21, 2015 at 7:06 PM, Eric Rahm er...@mozilla.com wrote: As part of the effort to improve logging in gecko we'd like to introduce a new set of unified log levels. Currently we use NSPR logging which defines the following log levels: typedef enum PRLogModuleLevel {

Re: PSA: The mochitest ise() function is dead, please use is() instead

On Wed, May 13, 2015 at 3:52 PM, Martin Thomson m...@mozilla.com wrote: On Wed, May 13, 2015 at 3:46 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: ise() was an alias to is() as of bug 949614. I landed bug 1154275 on inbound today which removes ise() and replaces its usages with is().

Re: Intent to remove: mochitest-flavor mach commands

On Wed, May 13, 2015 at 2:03 PM, Ms2ger ms2...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/13/2015 09:54 PM, Andrew Halberstadt wrote: As mentioned previously in another post, work is under way to remove the flavor specific mochitest commands (e.g mach

Mercurial 3.4 / Reporting Mercurial Issues / Birthday Party

Mercurial 3.4 was released on May 1. If you are an evolve user, I highly recommend upgrading for performance reasons. Everyone else should consider upgrading. But you may want to wait for 3.4.1 in case there are any regressions. More details with a link to the changelog and Mozilla-tailored

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

Wait - you're telling me that it is now possible to limit try pushes but not just jobs but tests within jobs?! Stop the presses: this is huge! If used by the masses, this could drastically reduce try turnaround times and decrease automation load and costs. Could we encourage use of --tag by

Re: Using rust in Gecko. rust-url compatibility

On Thu, Apr 30, 2015 at 3:34 PM, Valentin Gosu valentin.g...@gmail.com wrote: As some of you may know, Rust is approaching its 1.0 release in a couple of weeks. One of the major goals for Rust is using a rust library in Gecko. The specific one I'm working at the moment is adding rust-url as a

fx-team repository stripped

2 files summing to 90 MB of binary data (a Firefox installer) were checked into fx-team a few hours ago. While Mercurial (and Git) can handle binary files of this size, transferring excessively large files adds overhead to systems and is a barrier to contributors on slow connections. We therefore

Re: fx-team repository stripped

Yes and there is now bug 1157367 for that. On Wed, Apr 22, 2015 at 11:04 AM, Jeff Muizelaar jmuizel...@mozilla.com wrote: Should we have a hook to catch this kind of thing? -Jeff On Wed, Apr 22, 2015 at 1:44 PM, Gregory Szorc g...@mozilla.com wrote: 2 files summing to 90 MB of binary data

Re: Proposal to ban the usage of refcounted objects inside C++ lambdas in Gecko

On Fri, Apr 10, 2015 at 11:46 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: I would like to propose that we should ban the usage of refcounted objects inside lambdas in Gecko. Here is the reason: Consider the following code: nsINode* myNode; TakeLambda([]() { myNode-Foo(); });

Re: What are your pain points when running unittests?

Another pain point: running all relevant tests. Many features have relevant tests across many test suites, sometimes spread across different directories. When people are hacking on a feature, they should have a way to run all relevant tests for that feature. All too often I've submitted something

Re: What are your pain points when running unittests?

On Fri, Mar 13, 2015 at 3:49 PM, L. David Baron dba...@dbaron.org wrote: On Friday 2015-03-13 15:34 -0700, Gregory Szorc wrote: 1. Create a commit that introduces a new test 2. Test it 3. Create a commit that purportedly fixes the test 4. Build 5. Test and verify 6. Fold the commits

Re: Intent to not fix: Building with gcc-4.6 for Fx38+

On Wed, Mar 11, 2015 at 10:21 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2015-03-11 7:35 AM, Brian Smith wrote: Mike Hommey m...@glandium.org wrote: Brian Smith wrote: It is very inconvenient to have a minimum supported compiler version that we cannot even do test builds with

Re: Intent to not fix: Building with gcc-4.6 for Fx38+

On Wed, Mar 11, 2015 at 2:30 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2015-03-11 2:13 PM, Gregory Szorc wrote: On Wed, Mar 11, 2015 at 10:21 AM, Ehsan Akhgari ehsan.akhg...@gmail.com mailto:ehsan.akhg...@gmail.com wrote: On 2015-03-11 7:35 AM, Brian Smith wrote

Re: Help needed: define Bugzilla components in moz.build files

and checked in, I'll get it deployed somewhere more permanent. For now, ping me for feature requests. Hopefully the potential for this web service gets people thinking about the cool things that can be derived from it. On Tue, Mar 3, 2015 at 10:16 AM, Gregory Szorc g...@mozilla.com wrote

Re: Help needed: define Bugzilla components in moz.build files

I was accidentally sorting based on bug component name, not the count of bugs. The spreadsheet has been updated. Sorry for the confusion. On Wed, Mar 4, 2015 at 5:50 PM, Botond Ballo bba...@mozilla.com wrote: I see other wrongness in that spreadsheet, too. For example, for the first file I

Help needed: define Bugzilla components in moz.build files

Support for the previously announced [1] intention to use moz.build to define metadata for files has now landed on mozilla-central with the landing of bug 1132771 [2]. This is important to you because there are plans to leverage this metadata to make it easier to get stuff done. Some potential

Re: Capturing additional metadata in moz.build files

I'm starting to work on this implementation. https://reviewboard.mozilla.org/r/3817/ Feel free to comment on the diffs. https://reviewboard.mozilla.org/r/3935/diff/#0 is where it starts to get interesting. On Tue, Dec 9, 2014 at 10:46 AM, Gregory Szorc g...@mozilla.com wrote: In Portland

Re: User Repositories on hg.mozilla.org are Now Non-Publishing (Action May Be Required)

On Sat, Feb 14, 2015 at 9:21 AM, Ted Mielczarek t...@mielczarek.org wrote: On Fri, Feb 13, 2015, at 11:43 AM, Nathan Froyd wrote: On Fri, Feb 13, 2015 at 1:40 AM, Gregory Szorc g...@mozilla.com wrote: Truth be told, unless you are collaborating with other people using evolution

Re: User Repositories on hg.mozilla.org are Now Non-Publishing (Action May Be Required)

...@mozilla.com wrote: On Wednesday, February 11, 2015 at 1:04:55 PM UTC-8, Andrew Halberstadt wrote: Thank you very much! This gets around the last major pain point with using bookmarks. And yes, changeset evolution please :). On 10/02/15 06:37 PM, Gregory Szorc wrote: Mercurial has

User Repositories on hg.mozilla.org are Now Non-Publishing (Action May Be Required)

Mercurial has a feature called phases. When you push to a publishing repository, Mercurial sets the phase of the commit to public and Mercurial will refuse to let you modify/rewrite that commit. The purpose of this feature is to prevent you from footgunning yourself by rewriting history that has

Re: gecko-dev and Git replication will be broken for a little while

GitHub syncing has been restored. Replication on git.mozilla.org is still recovering. But we're over the big hump (getting the two systems to agree on SHA-1s). On Fri, Jan 30, 2015 at 5:01 PM, Gregory Szorc g...@mozilla.com wrote: I figured people would like an update. There were multiple

Re: gecko-dev and Git replication will be broken for a little while

On Fri, Jan 30, 2015 at 3:38 AM, Wander Lairson Costa wco...@mozilla.com wrote: On Thu, Jan 29, 2015 at 8:48 PM, Mike Hommey m...@glandium.org wrote: On Thu, Jan 29, 2015 at 12:31:35PM -0800, Gregory Szorc wrote: The steps within my control to potentially fix this issue have been postponed

Re: gecko-dev and Git replication will be broken for a little while

for service restoration. But people are working on it. I wish I had better news to report. On Thu, Jan 29, 2015 at 1:06 AM, Gregory Szorc g...@mozilla.com wrote: Git replication is currently broken due to a mistake of mine when mass closing branches earlier today. Don't expect restoration before

gecko-dev and Git replication will be broken for a little while

Git replication is currently broken due to a mistake of mine when mass closing branches earlier today. Don't expect restoration before 1200 PDT. Bug 927219. ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: gecko-dev and Git replication will be broken for a little while

On Thu, Jan 29, 2015 at 1:07 PM, Eric Rescorla e...@rtfm.com wrote: On Thu, Jan 29, 2015 at 12:31 PM, Gregory Szorc g...@mozilla.com wrote: The steps within my control to potentially fix this issue have been postponed until at least tomorrow due to the Firefox Beta build today. tl;dr

Re: gecko-dev and Git replication will be broken for a little while

another day for replication to turn on again. If you haven't tried Mercurial lately, you may want to. Read the Mercurial for Mozillians guide at http://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/index.html for some good pointers. On Thu, Jan 29, 2015 at 1:06 AM, Gregory

Re: JavaScript code coverage

I thought someone did experiments with the Debugger API and concluded that using it to capture code coverage was too slow to be practical: we need something built into the engine that is fast. Also, part of the Engineering Operations Strategic Plan is to provide better data and metrics (including

Re: Good ways to view Firefox compile errors in a terminal?

|mach warnings-list| and the underlying implementation to parse and store warnings [1] are one of the very first features of mach and there is definite room for improvement. If the functionality isn't doing what you want, send a patch to change it! We probably could integrate warning parsing into

Re: PSA: Support for building with Windows SDK 8.1 removed from Gecko 37

I recommend a 4+ physical core Ivy Bridge or newer i5/i7 CPU, 8+ GB of RAM (16 GB preferred), and an SSD. If you work for Mozilla and don't have that (e.g. you are building on a MacBook Air), please order a new machine right now. Anyone with less is going to have a bad time. I'm inclined to

Build errors related to psutil

If you see build system errors or warnings related to psutil when updating mozilla-central past a changeset from December 24, you should be able to work around them by deleting the following files: python/psutil/build (the whole directory) python/psutil/*.so (POSIX operating systems)

Re: PSA: Constructors callable with one argument should be marked as explicit/implicit

On 12/17/14 9:32 AM, Ehsan Akhgari wrote: On 2014-12-17 11:40 AM, Ted Mielczarek wrote: On 12/17/2014 10:19 AM, Ehsan Akhgari wrote: Apple unfortunately doesn't ship the headers and libraries required to build against that clang, and if you try to compile the plugin against headers/libraries

Re: Capturing additional metadata in moz.build files

On 12/10/14 9:48 AM, Ehsan Akhgari wrote: On 2014-12-10 12:30 PM, Benoit Girard wrote: On Tue, Dec 9, 2014 at 1:46 PM, Gregory Szorc g...@mozilla.com wrote: * Building a subscription service for watching code and reviews They all sound great. Except I'm not sure what you mean by this one

Re: prebuilt libraries?

On 11/27/14 1:05 AM, Thomas Zimmermann wrote: Hi Michael, Thank you for providing more information on the topic. [1] http://gittup.org/tup/build_system_rules_and_algorithms.pdf That was an interesting read and the numbers are quite impressive. However I'm skeptical of the overall approach,

Re: prebuilt libraries?

On 11/26/14 10:58 AM, Thomas Zimmermann wrote: Hi Am 26.11.2014 um 17:35 schrieb Michael Shal: Would it make sense to check in some of the libraries we build that we very rarely change, and that don’t have a lot of configure dependencies people twiddle with? (icu, pixman, cairo, vp8, vp9).

Re: prebuilt libraries?

On 11/26/14 2:36 PM, Mike Hommey wrote: On Wed, Nov 26, 2014 at 08:48:05AM -0800, Gregory Szorc wrote: In the high-level approach, you recognize what the final output is and jump straight to fetching that. e.g. if all you really need is libxul, you'll fetch libxul.so. None of this intermediary

Help make the build faster by porting make rules to the misc tier

We added a capability to the Firefox build system that will ultimately lead to speeding up the build and we need your help to realize its potential. Background == The Firefox build executes as a pipeline of stages called tiers. The tiers are currently export - compile - misc - libs -

Mailing list for version control discussion

version-control-...@mozilla.org is now a mailing list. Short term, we'll likely be talking about upgrading the server infrastructure and fixing Try. Long term, I imagine there will be some interesting discussions about more official Git support. If you care about version control or want to

Re: Mailing list for version control discussion

On 11/12/14 5:58 PM, Gregory Szorc wrote: version-control-...@mozilla.org is now a mailing list. Short term, we'll likely be talking about upgrading the server infrastructure and fixing Try. Long term, I imagine there will be some interesting discussions about more official Git support. If you

Re: MozReview ready for general use

On 11/12/14 10:39 PM, Dan Glastonbury wrote: Hi, I've been trying MozReview and I'm having trouble with updating a review with changes for my reviewers to verify. The documentation says, Oh, it just works, but in my case it doesn't. I'm using the evolve extension, so my repo have obsolescence

Re: MozReview ready for general use

On 11/10/14 9:14 AM, Gregory Szorc wrote: On 11/9/14 8:29 PM, Boris Zbarsky wrote: On 11/9/14, 11:10 PM, Gregory Szorc wrote: We currently only attempt to map each review/commit series to a single bug. This is definitely a problem; it serializes workflow such that you have to get review

Re: MozReview ready for general use

On 11/9/14 8:29 PM, Boris Zbarsky wrote: On 11/9/14, 11:10 PM, Gregory Szorc wrote: We currently only attempt to map each review/commit series to a single bug. This is definitely a problem; it serializes workflow such that you have to get review on bug 1 and land it before you can even

Re: MozReview ready for general use

We currently only attempt to map each review/commit series to a single bug. We will support multiple bugs eventually. Single bugs were easy to implement :) There is also an open bug to support specifying the base revision to review. Right now everything on the stack gets reviewed. That should

Re: Git - Hg workflows?

On 10/31/14 7:21 AM, Ehsan Akhgari wrote: On 2014-10-31 1:48 AM, Gregory Szorc wrote: a) Landing code to inbound, fx-team, aurora, etc I have the following git alias: hgp = show -M -C --binary --full-index --format=\From: %an %ae%nSubject: %s%n%n%b\ -U8 And my workflow for landing code

Re: Git - Hg workflows?

On 10/31/14 11:03 AM, Ehsan Akhgari wrote: On 2014-10-31 12:51 PM, Gregory Szorc wrote: All problems in computer science can be solved by another level of indirection. The problem here is that Git users need to push to the canonical Mercurial repositories (inbound, try, etc). You

Re: Git - Hg workflows?

On 10/30/14 10:48 PM, Gregory Szorc wrote: I'm trying to learn more about how the people who use Git for Firefox/Gecko development manage interacting with repositories that have their canonical home in Mercurial (mozilla-central, Try, etc). I'm doing this to ensure the replacement Try

Git - Hg workflows?

I'm trying to learn more about how the people who use Git for Firefox/Gecko development manage interacting with repositories that have their canonical home in Mercurial (mozilla-central, Try, etc). I'm doing this to ensure the replacement Try architecture will be usable by Git users. I'm

Re: Breakdown of Firefox full installer

On 10/15/14 3:25 AM, Henri Sivonen wrote: On Tue, Oct 14, 2014 at 3:37 AM, Chris Hofmann chofm...@mozilla.com wrote: Now that we have a strategy for putting developer tools in there own release What's that strategy? It could be very bad for us if Dev Tools didn't just work for Web devs

Re: Tool for generation of regression-range links

On 10/13/14 12:17 PM, Benjamin Smedberg wrote: tl;dr: I have a tool for generating regression-range links from buildids. http://bsmedberg.github.io/firefox-regression-range-finder/ Often times when we're investigating regressions (crashes, etc), we have the build ID of the nightly where the

Re: Breakdown of Firefox full installer

On 10/13/14 4:54 PM, Chris More wrote: Does anyone know or could any of you create a breakdown of the major blocks of the Firefox installer and each of their respective sizes or percentage of the whole? For example, the win32 installer for Firefox 32 is 34MB. The Firefox Growth team [1] like

Re: Breakdown of Firefox full installer

in that thread. I guess it was never acted upon. On Oct 13, 2014, at 5:39 PM, Gregory Szorc g...@mozilla.com wrote: On 10/13/14 4:54 PM, Chris More wrote: Does anyone know or could any of you create a breakdown of the major blocks of the Firefox installer and each of their respective sizes

Re: Documenting uses of Github at Mozilla

On 9/30/14 3:57 PM, Mike Hommey wrote: On Tue, Sep 30, 2014 at 03:44:36PM -0700, Ralph Giles wrote: https://github.com/mozillayvr/ Upstream libraries we import: https://github.com/kinetiknz/nestegg/ https://github.com/xiph/opus/ https://github.com/webmproject/libvpx and all the things that

Re: Using protobuf in m-c

On 9/24/14 10:38 AM, Fitzgerald, Nick wrote: Hey folks, We already have the protobuf library in the tree, and it seems to be used for layer scope and webrtc. I'd like to use it for serializing heap snapshots in devtools code, but I have a couple questions: * How do I integrate the compilation

<    1   2   3   4   5   6   >