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 MozPh
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
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 have
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
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. In
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.
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
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?
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
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 .hgignor
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 cloudflar
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] poi
Am 04.12.17 um 05:42 schrieb Jet Villegas:
On Sun, Dec 3, 2017 at 05:15 Axel Hecht <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 taskcluster
index
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:
*
.gecko.v2.{project}.revision.{head_rev}.{buil
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 defaults
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 tw
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 artific
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.
Th
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 sec
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 en
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 th
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 to do a bare-bones r
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 buy-
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 checkers?
[…], which implements
mo
Am 16/01/2017 um 21:43 schrieb Dave Townsend:
One of the things I've been investigating since moving back to the desktop
team is how we can remove XUL from the application as much as possible. The
benefits for doing this are varied, some obvious examples:
* XUL is a proprietary standard and we b
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
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 te
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 almost-worki
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 that
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
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 whatever gives us maxim
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
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 thi
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 and
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 us
does 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 wrote:
I haven't found localized builds and their assets by glancing at things.
Are those to come
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 a
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.
The first problem w
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 pa
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
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
panels
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
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.
Axe
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, R
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 the
On 12/19/14 6:20 AM, Chris Peterson wrote:
Here is the new Gmail calendar information for the weekly Platform
Engineering meeting. If these calendar links don't work, please let me
know.
* iCal ics link:
https://www.google.com/calendar/ical/mozilla.com_p51ksu9ddgqt72f0jl21vaq76o%40group.calend
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
acces
in https://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 o
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:
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
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
mission-cr
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 ord
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 idem
The feature of zip we want is the index, that let's us seek to a
position in the bundle and start unpacking, just given the filename.
How hard is to actually create a datastructure for the same purpose for
a tar.xz or so? I don't know really anything about the uncompression
algorithms to know
On 1/24/14 9:30 AM, Neil wrote:
Since we're not allowed to move locale files on branches, is it possible
for a jar.mn to refer to locale files from another part of the tree?
Yes, these days you can actually do that.
Look at what we're doing in mobile/android/locales/jar.mn, with the
chunks l
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 sys
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 t
On 11/25/13 12:16 PM, Henri Sivonen wrote:
Now that we have ICU in the tree, do we still need platform-specific
nsICollation implementations? In particular, the Windows and Unix back
ends look legacy enough that it seems that making nsICollation
ICU-backed would be a win.
We don't build ICU ye
On 11/21/13 8:43 PM, Laura Thomson
wrote:
I'll keep it short and to the point. Are there any objections to shutting down http://bonsai.mozilla.org/cvsqueryform.cgi ?
If you don't know what that is--and few people do, which is even more reason to shut it off--it's a
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 work
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
On 10/17/13 3:41 PM, Brian Smith wrote:
On Thu, Oct 17, 2013 at 3:46 AM, Axel Hecht 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 this
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,
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
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, curren
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
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 sh
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
__
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, and
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
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 thi
On 10/2/13 9:33 PM, Erik Rose wrote:
What features do you most use in MXR and DXR?
Over in the recently renamed Web Engineering group, we're working hard to
retire MXR. It hasn't been maintained for a long time, and there's a lot of
duplication between it and DXR, which rests upon a more moder
On 9/5/13 1:17 PM, Mike Hommey wrote:
On Thu, Sep 05, 2013 at 12:24:11PM +0200, Axel Hecht wrote:
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?
I didn't find any
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
file
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:
https://hg.mozilla.org/releases/mozilla-release
On 8/29/13 3:17 PM, Anne van Kesteren wrote:
On Thu, Aug 29, 2013 at 1:48 PM, Axel Hecht 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 the curren
On 8/29/13 12:03 PM, Henri Sivonen wrote:
On Thu, Aug 29, 2013 at 10:12 AM, Henri Sivonen 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 pointed to
https://mxr
On 8/28/13 1:12 PM, Anne van Kesteren wrote:
On Wednesday, February 27, 2013 12:28:43 PM UTC, Axel Hecht wrote:
That's rather orthogonal to what you're currently trying to do, but it's
also indicating to me that we should remove all of those settings from
intl.properties, and ju
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
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
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
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
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 Fallba
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
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 x
On 7/29/13 8:06 PM, Benjamin Smedberg wrote:
On 7/29/2013 1:43 PM, Gregory Szorc wrote:
I don't particularly care for our model of a single Mercurial
repository per logical entity. I think it makes sense for things like
twigs and to some extent integration repositories - you can do your
work in
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
O
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 wrote:
Establishing one-day turnaround time on reviews, or on requests, would require
a lot more polling on my review queue.
You poll your review queue? L
On 7/3/13 8:49 AM, Anne van Kesteren wrote:
On Tue, Jul 2, 2013 at 12:09 PM, Benjamin Smedberg
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 special known schemes in our
On 7/1/13 8:30 PM, Gavin Sharp wrote:
.sOn Mon, Jul 1, 2013 at 10:58 AM, Benjamin Smedberg
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 http://mozilla.org/
which is
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 t
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 so
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 see
On 5/3/13 1:36 AM, Gregory Szorc wrote:
On 5/2/2013 4:13 PM, Lawrence Mandel wrote:
- Original Message -
Great post, Taras!
Per IRC conversations, we'd like to move subsequent discussion of
actions into a meeting so we can more quickly arrive at a resolution.
Please meet in Gregory S
Hi,
what exactly does this do?
If I
mach build chrome
does it build the things I need to get everything in chrome built, or
does it build everything that depends on the chrome dir,
or both?
Axel
On 5/2/13 7:03 PM, Nick Alexander wrote:
Hello dev-platform,
If you don't use mach, this messag
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 infrastr
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
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 back
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.
bp-48ad9b29-145f-49ec-b282-5538f21304
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 mo
1 - 100 of 119 matches
Mail list logo