Re: Using MozPhab without Arcanist

Am 24.10.19 um 12:13 schrieb Henrik Skupin: glob wrote on 23.10.19 17:56: It's available now - make sure you're running the latest version by running `moz-phab self-update`. That's what I did yesterday, but as it looks like the self-update actually didn't update my version to the latest

mach lint -l l10n coming your way

Hi, I just landed a new linter into mach, and thus into treeherder and phabricator. It's called `l10n`, and `l1nt` on treeherder. It checks for common errors in localizable files, like duplicate strings and parsing errors, but also runs some more detailed checks. On phabricator, it also

Re: Patching FF 52.9esr with v60+ Security updates possible?

Disclaimer, I'm not a security expert, but a couple of thoughts: We have rewritten 52.x code in Rust, and we have removed features. If there are security vulnerabilities in the 52.x versions of that code, nobody is going to tell Mozilla. In that sense, it's unlikely that Mozilla will ever

Re: Improving our usage of Bugzilla

Am 02.04.19 um 19:24 schrieb Sylvestre Ledru: Because I had a few discussions about task vs enhancement, a good way to make the difference between the two use cases is: If I ever need help with this bug, should it come from someone in Product or an EPM? Can I ask for clarification? Is it task

Re: PSA: Min clang / libclang requirement was updated not long ago...

Am 27.02.19 um 15:28 schrieb Nathan Froyd: On Wed, Feb 27, 2019 at 9:05 AM Axel Hecht wrote: Am 27.02.19 um 14:39 schrieb Nathan Froyd: On Wed, Feb 27, 2019 at 6:22 AM Kartikaya Gupta wrote: On Wed, Feb 27, 2019 at 3:40 AM Axel Hecht wrote: Can we please not force bootstrap? +1

Re: PSA: Min clang / libclang requirement was updated not long ago...

Am 27.02.19 um 14:39 schrieb Nathan Froyd: On Wed, Feb 27, 2019 at 6:22 AM Kartikaya Gupta wrote: On Wed, Feb 27, 2019 at 3:40 AM Axel Hecht wrote: Can we please not force bootstrap? +1. In general bootstrap isn't "rock solid" enough to force people into running it. If p

Re: PSA: Min clang / libclang requirement was updated not long ago...

Can we please not force bootstrap? Background: As a python-heavy engineer, my relationship with homebrew is pretty broken these days. There's stuff that's essential to my day-to-day business that I had to take out of homebrew, including having my own compiles of python. I also have to have my

Re: New and improved "about:config" for Firefox Desktop

Is there a tracking bug for follow-ups? I'd have a few, adding pref w/out search (*), show add on screen for long searches, filter/order by modified, search in values, can't abort edit. (*) I just realize that I didn't understand how "add" works. Maybe the bug is to make that discoverable?

Re: C++ standards proposal for a embedding library

CCing snorp. I guess it's interesting to see how the geckoview API differs from the webview API, and which of those differences are related to goal of that C++ API, and which are more browser-focused. And if the C++ API should be also browser-focused, in the end. Not making any statement on

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

A couple of comments: One thing I'm missing is the ability to do mono-repo imports. Say we want to vendor in https://github.com/projectfluent/fluent.js/tree/master/fluent-gecko. For js libraries, we might also want to pay attention to .npmignore (others already mentioned hg, so also

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

I have a couple of further questions: One is about the legal impact on users. DNS mangling is part of law enforcement strategies in many parts of the world (incl Germany). We should restrict this experiment to regions where Mozilla knows that there's no legal trouble of using DoH and

Re: Password autofilling

Am 02.01.18 um 17:22 schrieb Gijs Kruitbosch: On 01/01/2018 20:08, Jonathan Kingston wrote: We have the ability to turn off the whole login manager within Firefox preferences: "Remember logins and passwords for web sites" but no way to prevent autofill. There's an about:config pref, as [1]

Re: INTENT TO DEPRECATE (taskcluster l10n routing)

Am 04.12.17 um 05:42 schrieb Jet Villegas: On Sun, Dec 3, 2017 at 05:15 Axel Hecht <l...@mozilla.com <mailto:l...@mozilla.com>> wrote: Am 01.12.17 um 16:45 schrieb Justin Wood: > Hey Everyone, > > tl;dr if you don't download nightly l10n repacks via

Re: INTENT TO DEPRECATE (taskcluster l10n routing)

Am 01.12.17 um 16:45 schrieb Justin Wood: Hey Everyone, tl;dr if you don't download nightly l10n repacks via taskcluster index routes, this does not affect you. Up until recently you could only find nightly l10n repacks with the following routes: *

Re: Proposal to remove some preferences override support

Looping in mkaply explicitly, if that has impact on organizational deployments. Axel Am 02.11.17 um 00:41 schrieb Nicholas Nethercote: Greetings, In https://bugzilla.mozilla.org/show_bug.cgi?id=1413413 I am planning to remove a couple of things relating to preferences. 1) Remove the

Re: Changes to tab min-width

Am 04.10.17 um 18:43 schrieb Jeff Griffiths: Om my system ( retina macbook pro ) 70 is starting to look like a better compromise for tab readability. How I have been testing this: - change the value to a specific number, say 70 - open enough tabs so that overflow triggers, then close

Changes to how we localize Firefox - one repository to rule a hundred repositories

Hi, tl;dr: We'll be using a single French, German, Slovenian localization across all of mozilla-central, -beta, -release, -esr-*, starting with 57. This change will ride the trains. We call it "cross channel localization", or x-channel in short. How does that work? We're creating an

Re: Mac/Win32/Win64 Nightly builds for some locales aren't being updated since 08-08

Am 11.08.17 um 11:07 schrieb rodrigo.mcu...@hotmail.com: Can someone enlighten me on why some locales' Nightly builds are not being updated since August 8th? This probably isn't the best place to post this, but I don't know if this is intended or not so I rather ask here than submit a bug.

Re: Phabricator and confidential reviews

To answer the question not asked ;-) I think we should strive to have as few people as possible with general access to security bugs. The concerns the folks have when crossing borders is awful. And just from a general risk profile. Saying that as someone that neither has nor wants access to

Creating a localized build locally

Hi, cross-posting this from https://blog.mozilla.org/l10n/2017/08/04/create-a-localized-build-locally/. Yesterday we changed the way that you create localized builds on mozilla-central. This works for developers doing regular builds, as well as developers or localizers without a compile

Re: More Rust code

Am 17.07.17 um 21:43 schrieb Ted Mielczarek: Nick, Thanks for kicking off this discussion! I felt like a broken record talking to people about this in SF. From my perspective Rust is our single-biggest competitive advantage for shipping Firefox, and every time we choose C++ over Rust we throw

Re: Scope of XML parser rewrite?

Am 24.05.17 um 09:34 schrieb Anne van Kesteren: On Tue, May 23, 2017 at 8:23 PM, Eric Rahm wrote: I was hoping to write a more thorough blog post about this proposal (I have some notes in a gist), but for now I've added comments inline. The main takeaway here is that I want

Re: Scope of XML parser rewrite?

Am 23.05.17 um 16:01 schrieb Daniel Fath: So, if I understand this correctly - We'll first need to land this component in Firefox, right? And if it proves itself fine, then formalize it. I was thinking of having resolutions for the issues that are currently warnings in red and multi-vendor

Re: Future of out-of-tree spell checkers?

Am 22.03.17 um 15:39 schrieb Jorge Villalobos: On 3/22/17 8:10 AM, Henri Sivonen wrote: On Wed, Mar 22, 2017 at 3:52 PM, Nicolas B. Pierron wrote: On 03/22/2017 09:18 AM, Henri Sivonen wrote: Without XPCOM extensions, what's the story for out-of-tree spell

fyi, ./mach hangs on terminal-notifier? brew update to 1.7.1

Hi, as an fyi, I almost filed a bug on mach hanging on terminal-notifier after the end of a build or packaging step. Seems that was a bug in terminal-notifier 1.7.0, another brew update/upgrade updated that to 1.7.1 and fixed it. Just in case you've been in that boat. Axel

Re: Removal of B2G from mozilla-central

On 04/10/16 17:40, Fabrice Desre wrote: On 10/04/2016 08:34 AM, Axel Hecht wrote: I'd favor to remove at least anything related to l10n from b2g. It never really worked, and is a half-maintained copy of the almost-working stuff in mobile. In my local branches that try to create a test

Re: Removal of B2G from mozilla-central

On 04/10/16 12:16, Gabriele Svelto wrote: * b2g ~20K lines which would also drop considerably due to the removal of the APIs, completely self-contained I'd favor to remove at least anything related to l10n from b2g. It never really worked, and is a half-maintained copy of the

Re: Questions about bindings for L20n

On 14/06/16 05:06, zbranie...@mozilla.com wrote: On Monday, June 13, 2016 at 9:39:32 AM UTC+1, Gijs Kruitbosch wrote: > Separately, the documentation put forth so far seems to indicate that the localization itself is also async, on top of the asyncness of the mutationobserver approach, and

Re: Triage Plan for Firefox Components

Hi Emma, for those of us that are addicted to data: You have about a 1000 bugs of data, and I'd love to hear some of the good parts, and maybe also some of the bad parts. Also, you tested on three teams, and you report a success story from one. Could you frame that a bit? Is that within the

Re: Proposing preferring Clang over GCC for developer buidls

On 03/03/16 01:57, Jeff Gilbert wrote: On Wed, Mar 2, 2016 at 3:45 PM, Mike Hommey wrote: More importantly, changing the official toolchain has implications on performance. Sorry, I meant for general automation. Our final spins (especially LTO/PGO builds) should remain

Re: rr chaos mode update

On 16/02/16 03:15, Kyle Huey wrote: Seems like a good thing to expect developers to do locally today. Two concerns: What's the successs criteria here? Also, speaking as an occasional code contributor, newcomers and folks like me will probably give up on contributing patches earlier. Axel

Re: Bug Program Next Steps

Hi, I'd like to start my feedback with a request. It'd help me to get a big-picture of the stuff that surrounds this email. Things I'd like to see is information about who's been consulted going in to this. Also, which threads about bug lifecycle got looked at. It'd also be nice to see how

Re: Just Autoland It

Piling on: I'm using mozreview mostly as an occasional patch author: Plus, I can schedule a try build. Minus, I need to bother the reviewer with a published request in order to do so. Resorted to add yet another hg extension to my local .hg/hgrc. My most frequent concern is that bugzilla

Re: Improving blame in Mercurial

On 12/11/15 10:46 PM, Joshua Cranmer  wrote: On 12/11/2015 5:17 PM, Gregory Szorc wrote: If you have ideas for making the blame/annotate functionality better, please capture them at https://www.mercurial-scm.org/wiki/BlamePlan or let me know by replying to this message. Your feedback will be

Re: Using the Taskcluster index to find builds

one distinguish nightlies from non-nightlies under mozilla-central.latest? Assuming that nightlies might end up there on occasion? Axel On Tue, Dec 1, 2015 at 5:22 AM, Axel Hecht <l...@mozilla.com> wrote: I haven't found localized builds and their assets by glancing at things. Are

Re: Using the Taskcluster index to find builds

I haven't found localized builds and their assets by glancing at things. Are those to come? Also, I suspect we should rewrite wget-en-US? Or add an alternative that's index-bound? Axel On 11/30/15 9:43 PM, Chris AtLee wrote: The RelEng, Cloud Services and Taskcluster teams have been doing

Re: Why do we flush layout in nsDocumentViewer::LoadComplete?

On 11/27/15 4:09 AM, Robert O'Callahan wrote: On Fri, Nov 27, 2015 at 3:59 PM, Boris Zbarsky wrote: On 11/26/15 9:24 PM, Robert O'Callahan wrote: We've always done it, but I can't think of any good reasons. I've tried to fix this in the past and ran into two problems.

Re: Merge moved to Thursday 29th

I'm also commented in the bug: If we're doing uplifts, I'm not sure we're winning by uplifting pre-landed strings. Either way, I think the risk assessment of the patch should be that of the actual patch that uses the strings, not "just adding strings". Also, I'd appreciate an ETA for the

Default window size on a screen of 1920x1080 or 1280x1024?

Hi, we're trying to find out what the default window size would be for people on screens of 1920x1080 or 1280x1024. Sadly, I can't find the code that actually computes that for the heck of it, can anybody help? Background: We want to ensure that the new about:privatebrowsing has the

Re: Default window size on a screen of 1920x1080 or 1280x1024?

Thanks, exactly what I was looking for. Axel On 9/16/15 7:13 PM, Gavin Sharp wrote: See https://hg.mozilla.org/mozilla-central/annotate/3e8dde8f8c17/browser/base/content/browser.js#l1017 if you're wondering about Firefox specifically. Gavin On Wed, Sep 16, 2015 at 7:26 AM, Axel Hecht &l

Re: Largest chunks of code that are likely to be removable?

On 6/30/15 9:13 AM, Mike Hommey wrote: On Mon, Jun 29, 2015 at 11:19:08PM -0700, Nicholas Nethercote wrote: Hi, I'm wondering what the largest chunks of code there are in the codebase that are candidates for removal, i.e. probably with a bit of work but not too much. One that comes to mind is

Re: Voting in BMO

I recall that at least one group actively uses votes to prioritize stuff. I can't really tell which one, I'm leaning towards devtools, but I don't have any data to back that up. I mostly remember because I was surprised. Also, for a component like devtools, I can see how it'd make sense.

Re: Mozillabuild 2.0 ready for testing

Hi Ryan, good news. One thing that's a bit unfortunate from the l10n perspective is the svn drop. SVN is still used quite frequently to host the website localizations, so keeping that in would be helpful. Axel, who should probably give this a test run in reals on his VM. On 3/9/15 2:44 AM,

Testing for expected crashes in both C++ and js, for printf checking

Hi, I'd like to write tests to validate my assumptions around what's an error and what's a warning for localized values going into nsTextFormatter::smprintf. Basically, the tests would start with a reference string, and then a more or less random modification of that string, and a check if

Re: Deprecating localstore.rdf

On 8/4/14 9:55 PM, Benjamin Smedberg wrote: On 7/22/2014 8:47 AM, Roberto Agostino Vitillo wrote: Localstore.rdf will soon be replaced with a json store (see Bug 559505). I am currently planning to leave the localstore.rdf implementation as it is and issue a warning when a client tries to

Re: .properties and a single \u

://bugzilla.mozilla.org/show_bug.cgi?id=1040019. Axel On 7/11/14 4:26 PM, Axel Hecht wrote: Hi, in .properties foo = some \unicode bar = some \a creates the most icky output. I'd like to get a defined behavior, but it turns out to be hard. Java: - dies with a parsing error on foo, bar is some

.properties and a single \u

Hi, in .properties foo = some \unicode bar = some \a creates the most icky output. I'd like to get a defined behavior, but it turns out to be hard. Java: - dies with a parsing error on foo, bar is some a XPCOM: - returns some , as \u is converted to \0 on foo, bar is some a Gaia: -

Re: Where is the document for jar.mn file format

On 7/2/14 12:25 PM, Yonggang Luo wrote: I am using Mozilla XUL SDK to build my own application, So I'd like to know what's the format of jar.mn file Took me a while to find it, but I think that https://ci.mozilla.org/job/mozilla-central-docs/Tree_Documentation/buildsystem/jar-manifests.html

Re: Spring cleaning: Reducing Number Footprint of HG Repos

On 3/27/14, 12:53 AM, Taras Glek wrote: *User Repos* TLDR: I would like to make user repos read-only by April 30th. We should archive them by May 31st. Time spent operating user repositories could be spent reducing our end-to-end continuous integration cycles. These do not seem like

Re: How to efficiently walk the DOM tree and its strings

Hi, translating DOM is a bit funky. Generally, you can probably translate block elements one by one, but you need to persist inline elements. You should mark up the inline elements in the string that you send to the translation engine, such that you can support inline markup changing the

Re: Changing how build automation interacts with the tree

Hi, I've watched you guys thinking for an hour ;-) Some comments from me. Yes to moving build flows that generate assets into the tree. Yes to having a way for developers to reproduce what automation does. Yes to having jobs being executed more on demand than on push, and having that have

Re: W3C Proposed Recommendations: RDF 1.1

As, still, module owner of RDF, I think that's the right thing for us to do. I haven't actually followed the development of the specs, but I'm positive that the development of those specifications doesn't impact us as a browser vendor. The impact of RDF is in the web application and addons

Re: A proposal to reduce the number of styles in Mozilla code

Hi, two points of caution: In the little version control archaeology I do, I hit breaks blame for no good reason pretty often already. I'd not underestimate the cost for the project of doing changes just for the sake of changes. Tools don't get code right. I've seen various changes where

Re: Add-on File Registration PRD

On 11/4/13 9:41 AM, Onno Ekker wrote: Jorge Villalobos wrote: Cross posting to dev.planning, where I originally intended this to be. Please follow up to dev.planning. Jorge On 10/30/13 3:42 PM, Jorge Villalobos wrote: Hello! As many of you know, the Add-ons Team, User Advocacy Team, Firefox

Re: Add-on File Registration PRD

Hi, read the thread now. I ignored it based on the subject, btw, didn't seem to affect anything in real life from just glancing at that. I'd like to get langpacks excluded. Maybe we need to make their abilities to do stuff more robustly checked, but for a localizer wanting to test their

Re: Cost of ICU data

On 10/17/13 12:02 PM, Gervase Markham wrote: On 16/10/13 16:02, Axel Hecht wrote: We'll need to go down a path that works for Firefox OS. With Firefox OS, we don't have the download-size issue, do we? So we can ship all the data. Gerv We have issues with disk space, currently. We're

Re: Cost of ICU data

On 10/16/13 5:39 PM, Jeff Walden wrote: On 10/16/2013 02:10 PM, Axel Hecht wrote: I wonder how far we can get by doing something along the lines we use for webfonts, starting to do the best we can with the data we already have, and improve once the perfect data is local. Having the Intl.Foo

Re: Cost of ICU data

On 10/17/13 2:41 PM, Dao wrote: On 16.10.2013 17:02, Axel Hecht wrote: We'll need to go down a path that works for Firefox OS. [...] But, yes, I think we'll need a hosted service to provide that data on demand in the end. This sounds like a non-starter for mobile devices, doesn't

Re: Cost of ICU data

On 10/17/13 3:41 PM, Brian Smith wrote: On Thu, Oct 17, 2013 at 3:46 AM, Axel Hecht l...@mozilla.com wrote: We have issues with disk space, currently. We're already in the situation where all our keyboard data doesn't fit on quite a few of the devices out there. Where can one read more about

Re: Cost of ICU data

Jumping in late, so top posting. I think being able to load language data dynamically is a good idea. I don't see a reason why this should be tied in to a language pack, though. The other way around is a different question. i.e. language data doesn't include UI localization UI localization

Re: Cost of ICU data

On 10/16/13 3:50 PM, Gervase Markham wrote: On 16/10/13 14:47, Anne van Kesteren wrote: The API is synchronous so that seems like a bad idea. As in, it'll cause the tab to freeze (one time only, when a new language is called for) while the file is downloading? OK, that's bad, but so is having

Re: What platform features can we kill?

On 10/11/13 2:47 PM, David Rajchenbach-Teller wrote: I'd be happy if we could progressively kill FileUtils.jsm and make nsIFile [noscript]. Don't know if this qualifies as platform feature, though. Cheers, David Both are heavily used in the js build system for gaia, fwiw. Axel

Re: What platform features can we kill?

On 10/10/13 2:36 AM, Zack Weinberg wrote: On 2013-10-09 12:01 PM, Gervase Markham wrote: In the spirit of learning from this, what's next on the chopping block? In between keep the C++ implementation and scrap entirely is reimplement in JS, and I think that should be seriously considered for

Re: What platform features can we kill?

On 10/10/13 2:43 PM, Jeff Walden wrote: On 10/10/2013 02:27 PM, Axel Hecht wrote: I agree with the sentiment, but not on the eample. Having been a peer of the XSLT module back in the days, we started with a rather js DOM like implementation, and moved over to a pure nsIContent etc impl

Re: What platform features can we kill?

On 10/9/13 6:18 PM, Boris Zbarsky wrote: On 10/9/13 12:01 PM, Gervase Markham wrote: In the spirit of learning from this, what's next on the chopping block? RDF Yes. I think that localstore.rdf is the long pole. Not so much because we abuse it for xul persistance, that's OK to fix. The

Re: No more Makefile.in boilerplate

Hi, out of curiousity, I recall that relativesrcdir was actually the trigger to switch on and off some l10n functionality in jar packaging. Is that now on everywhere? Axel On 9/5/13 2:34 AM, Mike Hommey wrote: Hi, Assuming it sticks, bug 912293 made it unnecessary to start Makefile.in

Re: Getting the current release version

On 8/30/13 4:14 PM, Ed Morley wrote: On 30 August 2013 15:09:08, Eric Shepherd wrote: This could even be a place in the source code we could pull up a MXR link and peel out of the code. I just don't know where in the code to get it. For platform:

Re: Getting the current UI locale from C++

On 8/29/13 12:03 PM, Henri Sivonen wrote: On Thu, Aug 29, 2013 at 10:12 AM, Henri Sivonen hsivo...@hsivonen.fi wrote: How do I get the language code for the currently active UI language pack from within Gecko C++ code in a way that works across desktop, Android, B2G and Metro? On IRC, I was

Re: Getting the current UI locale from C++

On 8/29/13 3:17 PM, Anne van Kesteren wrote: On Thu, Aug 29, 2013 at 1:48 PM, Axel Hecht l...@mozilla.com wrote: I'll read up on the other thread, and I still think the approach is wrong here, sorry. You'll have to explain that more fully I think. This is the current approach. However

Re: Feedback wanted on font checker

On 8/13/13 8:05 AM, Karl Tomlinson wrote: On Fri, 09 Aug 2013 13:51:45 +0200, Axel Hecht wrote: To clarify, the tool does support either .name. or .name-list. at this point. Is there a code path or a setup where we have for any language/family both a .name. and a .name-list. entry? I.e. pref

Re: Feedback wanted on font checker

On 8/9/13 5:28 PM, Jonathan Kew wrote: On 9/8/13 15:36, Axel Hecht wrote: So I created three test cases based on the data I see, Greek and Bulgarian monospace and Hindi sans-serif. They're linked off of http://pike.github.io/fonts/. It's prerendered images on the left column, and regular

Re: Feedback wanted on font checker

On 8/9/13 1:27 PM, Karl Tomlinson wrote: Axel Hecht writes: On 8/8/13 10:45 PM, Karl Tomlinson wrote: Axel Hecht writes: On 8/8/13 5:17 PM, Jonathan Kew wrote: On 8/8/13 15:17, Axel Hecht wrote: Couter example seems to be Chinese, the unagi shows something, while my tool reports 13k

Re: Feedback wanted on font checker

On 8/9/13 1:51 PM, Axel Hecht wrote: On 8/9/13 1:27 PM, Karl Tomlinson wrote: Axel Hecht writes: On 8/8/13 10:45 PM, Karl Tomlinson wrote: Axel Hecht writes: On 8/8/13 5:17 PM, Jonathan Kew wrote: On 8/8/13 15:17, Axel Hecht wrote: Couter example seems to be Chinese, the unagi shows

Feedback wanted on font checker

Hi, I'm looking for a review of some rather hacky tool I just created to see if the fonts on b2g actually support a particular language. https://github.com/Pike/font-tool Basic outline of what the tool does: Parses langGroups.properties to see which locale has which group, with default to

Re: Feedback wanted on font checker

Hi Jonathan, thanks for the feedback, more inline. On 8/8/13 5:17 PM, Jonathan Kew wrote: On 8/8/13 15:17, Axel Hecht wrote: Hi, I'm looking for a review of some rather hacky tool I just created to see if the fonts on b2g actually support a particular language. https://github.com/Pike/font

Re: Feedback wanted on font checker

On 8/8/13 10:45 PM, Karl Tomlinson wrote: Axel Hecht writes: On 8/8/13 5:17 PM, Jonathan Kew wrote: On 8/8/13 15:17, Axel Hecht wrote: Couter example seems to be Chinese, the unagi shows something, while my tool reports 13k missing glyphs for zh-TW. If we're using Droid Sans Fallback, I

Re: Three RDFa-related W3C Proposed (Edited) Recommendations

I've only quickly glanced at those, and I haven't followed those discussions at all, I have to admit. Are there any practical consequences for gecko/firefox? It doesn't look like it would, in particular when looking at the reference implementations being all on top of html platforms. Axel

Re: review stop-energy (was 24hour review)

On 7/11/13 8:24 PM, Jeff Walden wrote: On 07/11/2013 03:09 AM, Nicholas Nethercote wrote: On Thu, Jul 11, 2013 at 7:48 AM, Jeff Walden jwalden+...@mit.edu wrote: Establishing one-day turnaround time on reviews, or on requests, would require a lot more polling on my review queue. You poll

Re: Embracing git usage for Firefox/Gecko development?

On 5/31/13 10:14 PM, Johnny Stenback wrote: On 5/31/2013 12:32 AM, Mike Hommey wrote: [...] Option 1 is where I personally think it's worth investing effort. It means we'd need to set up an atomic bidirectional bridge between hg and git (which I'm told is doable, and there are even commercial

Re: Embracing git usage for Firefox/Gecko development?

Weirdly enough, I'm hoping we're using one or the other, and I think git is more promising. Yes, I need to rewrite a bunch of stuff l10n-wise, but still. I actually think that we should aim high. Don't bother about command lines, but what takes us to a system where people can just contribute

Re: Replacing Gecko's URL parser

On 7/1/13 8:30 PM, Gavin Sharp wrote: .sOn Mon, Jul 1, 2013 at 10:58 AM, Benjamin Smedberg benja...@smedbergs.us wrote: Idempotent: Currently Gecko's parser and the URL Standard's parser are not idempotent. E.g. http://@/mozilla.org/ becomes http:///mozilla.org/ which when parsed becomes

Re: Replacing Gecko's URL parser

On 7/3/13 8:49 AM, Anne van Kesteren wrote: On Tue, Jul 2, 2013 at 12:09 PM, Benjamin Smedberg benja...@smedbergs.us wrote: Both resource: and chrome: have host names and need to support relative URIs. Neither of them is a candidate for standardization, though. We should just add them as

Re: Geolocation and the Mac

On 5/22/13 1:45 AM, Doug Turner wrote: In Bug 874587, we are considering using Core Location as the default geolocation provider on the Mac. This would replace the use of the NetworkGeolocationProvider (that currently points to GLS). After code reviews, we plan to enable this on Nightly and

Re: Proposal for an inbound2 branch

On 4/30/13 8:46 AM, Gregory Szorc wrote: On 4/26/2013 12:17 PM, Ryan VanderMeulen wrote: Specific goals: -Offer an alternative branch for developers to push to during extended inbound closures -Avoid patch pile-up after inbound re-opens from a long closure Specific non-goals: -Reducing

Re: Some data on mozilla-inbound

On 4/22/13 9:54 PM, Kartikaya Gupta wrote: TL;DR: * Inbound is closed 25% of the time * Turning off coalescing could increase resource usage by up to 60% (but probably less than this). * We spend 24% of our machine resources on changes that are later backed out, or changes that are doing the

Re: Some data on mozilla-inbound

On 4/23/13 6:35 PM, Kartikaya Gupta wrote: On 13-04-23 03:57 , Axel Hecht wrote: Do we know how many of these have been pushed to try, and passed/compiled what they'd fail later? I haven't looked at this. It would be useful to know but short of pulling patches and using some similarity

Nightly *very* crashy on OSX

Hi, I'm having a very crashy nightly, uptime below an hour, not really bound to a site. Might be https://bugzilla.mozilla.org/show_bug.cgi?id=864125, but I've experienced a bunch of crashes, all with pretty non-existing stack traces of no or one frame.

Re: Decoupling the build config via moz.build files (nuking all.js)

On 15.03.13 20:06, Benjamin Smedberg wrote: On 3/15/2013 2:33 PM, Gregory Szorc wrote: I /think/ our current spaghetti configuration is a historical artifact from using Makefile.in's to define the build config combined with the complexity required to do things right. Yes, I believe you are

Re: Review of changes to Web compat-sensitive prefs in localizations

On 27.02.13 09:30, Henri Sivonen wrote: On Fri, Feb 22, 2013 at 8:03 PM, Axel Hecht l...@mozilla.com wrote: On 22.02.13 18:41, Henri Sivonen wrote: On Feb 22, 2013 5:30 PM, Axel Hecht l...@mozilla.com wrote: There's just no other way than post-mortem work. That's one of the reasons why

Re: Review of changes to Web compat-sensitive prefs in localizations

On 22.02.13 15:37, Henri Sivonen wrote: I've been finding and, to a lesser extent, reporting and writing patches for bugs where a localization sets the fallback encoding to a value that doesn't suit the purpose of the fallback. In some cases, there such bogosity in the intl.properties file (e.g.

Re: Review of changes to Web compat-sensitive prefs in localizations

On 22.02.13 20:02, L. David Baron wrote: On Friday 2013-02-22 16:37 +0200, Henri Sivonen wrote: I've been finding and, to a lesser extent, reporting and writing patches for bugs where a localization sets the fallback encoding to a value that doesn't suit the purpose of the fallback. In some

Re: Sparse localizations of toolkit and the chrome registry's getSelectedLocale()

On 12.02.13 22:12, Axel Hecht wrote: On 12.02.13 20:27, Benjamin Smedberg wrote: On 2/12/2013 12:41 PM, Axel Hecht wrote: Hi Benjamin, Dave, for mobile (and fxos) we're looking into doing sparse localizations of toolkit. The work on the mobile side is bug 792077. The current attempt

Sparse localizations of toolkit and the chrome registry's getSelectedLocale()

Hi Benjamin, Dave, for mobile (and fxos) we're looking into doing sparse localizations of toolkit. The work on the mobile side is bug 792077. The current attempt is to leave the 'global' and other toolkit packages untranslated, and use chrome overrides to supply a few localized files, as

Re: Sparse localizations of toolkit and the chrome registry's getSelectedLocale()

On 12.02.13 20:27, Benjamin Smedberg wrote: On 2/12/2013 12:41 PM, Axel Hecht wrote: Hi Benjamin, Dave, for mobile (and fxos) we're looking into doing sparse localizations of toolkit. The work on the mobile side is bug 792077. The current attempt is to leave the 'global' and other toolkit

Re: mozilla-central/inbound closed -- we hit the Windows PGO memory limit

How are the perf numbers looking? One of the reasons for asking is that I expect RDF to be part of the startup and window-open codepaths, at least. I'm not overly concerned, but wanted to make sure we look. Axel On 22.01.13 15:06, Ehsan Akhgari wrote: Status update #3: It seems like with

Re: Integrating ICU into Mozilla build

On 07.12.12 01:08, Asa Dotzler wrote: On 12/3/2012 2:39 PM, Norbert Lindenberg wrote: Well, the first question is what size increase would be acceptable given the benefits that ICU provides. I don't understand what benefits this actually provides. How are users' online lives improved by this

Re: Extending jar.mn to support cross-module overrides

and mobile's custom built search-jar). Ted? I'd hack on that, fwiw, and I'd do so quickly, as we'll want this in 18 for b2g :-/ Axel On 01.10.12 21:13, Axel Hecht wrote: Hi, for both android and b2g, we end up only needing a handful of localized files from toolkit. I propose to extend JarMaker.py

Re: Extending jar.mn to support cross-module overrides

On 03.10.12 14:33, Mike Hommey wrote: On Wed, Oct 03, 2012 at 02:01:02PM +0200, Axel Hecht wrote: I've looked a bit deeper into the code, and there's unused functionality that I'd like to rip out of JarMaker.py in favor of this: Support for multiple jars in one go is one thing I'd love to axe

Re: Extending jar.mn to support cross-module overrides

On 03.10.12 15:41, Mike Hommey wrote: On Wed, Oct 03, 2012 at 02:54:19PM +0200, Axel Hecht wrote: On 03.10.12 14:33, Mike Hommey wrote: On Wed, Oct 03, 2012 at 02:01:02PM +0200, Axel Hecht wrote: I've looked a bit deeper into the code, and there's unused functionality that I'd like to rip out

Extending jar.mn to support cross-module overrides

Hi, for both android and b2g, we end up only needing a handful of localized files from toolkit. I propose to extend JarMaker.py and jar.mn to support something like a fake relativesrcdir, say @relativesrcdir toolkit/locales and then the following lines would pick up files from

  1   2   >