On Tuesday, 10 April 2018 00:57:43 UTC-7, Gijs Kruitbosch wrote:
> On 10/04/2018 03:07, Cameron McCormack wrote:
> > On Tue, Apr 10, 2018, at 11:58 AM, Jeff Gilbert wrote:
> >> Do we have a heuristic for when to /not/ include something from HTML in
> >> SVG?
> >
> > If it doesn't make two featur
Hi all, so as not to leave this hanging:
On Tue, Jan 17, 2017 at 9:24 AM, Axel Hecht wrote:
> Am 16/01/2017 um 21:43 schrieb Dave Townsend:
>
>>
>> What other features do we depend on in XUL that I haven't listed?
>>
>>
> Accessibility? Not sure how big the difference is there between XUL and
>
itself. I would be very skeptical of a
> plan to start using some form of heavily-XBL-reliant HTML.
>
> I have generally ambivalent feelings towards XUL, but XBL cannot die fast
> enough.
>
Should (can) it die in the Quantum development timeframe? What does that
do to shipping risk?
Bug 1231711, but I never got to do it, unfortunately.
On 26/01/17 08:01, zbranie...@mozilla.com wrote:
> On Thursday, November 10, 2016 at 5:15:26 AM UTC-8, David Teller wrote:
>> Ok. My usecase is the reimplementation of OS.File in Rust, which should
>> be pretty straightforward
Unfortunately, we will need to postpone the changeover and it will not
be happening tomorrow as announced. Due to some unplanned changes
related to security and also some blockers are still being worked on, it
has taken longer then expected to bring you the best possible experience
for the new defa
I have raised a bug[1] to block these types of commits in the future. This
is an unnecessary risk that we are taking.
I also think that we need to remove this as acceptable practice from the
MDN page.
David
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1336459
On 3 February 2017 at 15:11
oes outside of
https://developer.mozilla.org/docs/Mozilla/Developer_guide/C
ommitting_Rules_and_Responsibilities will be followed up.
David
On 3 February 2017 at 19:01, Steve Fink wrote:
> On 02/03/2017 09:29 AM, Gijs Kruitbosch wrote:
>
>> On 03/02/2017 15:11, Ryan VanderMeulen wrote:
Is there a specific problem that's being solved by this proposal? It would
be helpful to make this a bit more concrete, like "these benchmarks go x%
faster", or "here's a list of overflow bugs that will just vanish", or
"here's some upcoming work that this would facilitate".
On Thu, Feb 9, 2017 at
Nice!
I see that these fields are available in Super Search already, which is
great. This is going to make search queries really powerful.
On Tue, Feb 14, 2017, at 12:37 PM, Nicholas Nethercote wrote:
> Hi,
>
> For a long time we have collected a memory report for most crash reports
> where the
One thing I like about trailing operators is that they tend to match
what you'd find in bullet-point prose. Here's a made-up example:
You can apply for a refund of your travel insurance policy if:
* You cancel within 7 days of purchase, and
* You have not yet begun your journey, and
* You have not
3046
--
David Lawrence
d...@mozilla.com
bugzilla.mozilla.org
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
estions/raise:
* the feature is not implemented yet
* other browsers vendors are reading the "intent to" emails, so there is an
opportunity for this question to be fixed in an interoperable manner
David
Le mercredi 11 janvier 2017 18:34:56 UTC+1, Boris Zbarsky a écrit :
> When add
Today, the BMO Team changed the default bug view to the new modal
view that has been in development for a while. For those who would like
to use the old form, instructions on how to switch back are below in the
background information. The old form will, however, be removed one day,
so please try
t; On 01/03/2017 21:47, David Lawrence wrote:
>> Today, the BMO Team changed the default bug view to the new modal
>> view that has been in development for a while.
>
> I like the fact that you can now change the Product in one step.
>
> Sadly when resolving a bug,
show this but when I look at https://futurama.
theautomatedtester.co.uk/ each week I have seen this result consistenly
for about a month.
David
On 7 March 2017 at 09:03, Carsten Book wrote:
> Hi Lawrence,
>
> most (i would say 95 %) of the backouts are for Code issues - this include
ecdotal as to why there is a difference.
David
On 7 March 2017 at 12:57, Boris Zbarsky wrote:
> On 3/7/17 6:23 AM, David Burns wrote:
>
>>- Autoland 6%.(24 backouts out of 381 pushes)
>>- Inbound 12% (30 backouts out of 251 pushes)
>>
>
> Were those full b
not allow us to fail
forward like inbound without having to get a sheriff to land the code.
I think, and this is my next area to investigate, is the 1 bug per push
(the autoland model) could be helping with the percentage of backouts being
lower.
David
On 7 March 2017 at 21:29, Chris Peterson
e security problem and fix our nit problem instead
of bashing that we can't handle re-reviews because of nits.
David
On 9 March 2017 at 21:53, Mike Connor wrote:
> (please direct followups to dev-planning, cross-posting to governance,
> firefox-dev, dev-platform)
>
>
> Near
let me know. (I'm already aware of the servo bindings and will
address those)
Thanks,
David
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Try using Sysinternals Process Monitor to see what files MsMpEng.exe is
reading.
On Fri, Mar 17, 2017, at 04:26 PM, Ben Kelly wrote:
> Hi all,
>
> I'm trying to configure my new windows build machine and noticed that
> builds were still somewhat slow. I did:
>
> 1) Put it in high performance po
disable until they are all gone
then we have dead code in the tree and still no one to own it. Its a longer
process that could end up at the same end point.
David
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
I'd like to add to this a reminder that commit messages should describe
the _change_ and not the _symptom_. In other words, "Bug XYZ: Crash at
Foo::Bar" is not a good summary.
This is implied by what Boris said, but I've seen enough of these on my
pulsebot backscroll that it's worth mentioning exp
Hi All,
If you are working on web exposed features could you please take a few
minutes to complete the survey. This will help us prioritize work on Web
Platform Tests which helps us with our web compatibility story.
David
-- Forwarded message --
From:
Date: 28 April 2017 at 14
Hi,
The Gecko Profiler used to be notoriously unstable on 64-bit Windows. (If
you're curious: it's mostly because the unwinding rules for Win64 require
the system libraries to do a lot of synchronization, which our stack walker
would often call in ways that could deadlock.)
Ever since the last Qu
?
Also, I had the impression that Quantum DOM scheduling made JS event
loop spinning unncessary. Did I miss something?
Cheers,
David
On 5/19/17 1:38 AM, Bill McCloskey wrote:
> Hi everyone,
>
> One of the challenges of the Quantum DOM project is that we will soon have
> multiple "
I'm not sure if this is exactly the same as the ALLOW_COMPILER_WARNINGS
that we use for warnings-on-errors, but FWIW as of a couple of months
ago I cleaned out the last warning-allowance in our "own" code.
ALLOW_COMPILER_WARNINGS usage is now only in external libraries (I'm
counting NSS and NSPR as
E%3D2016-12-05T14%3A42%3A31.000Z&date=%3C2017-06-05T14%3A42%3A31.000Z#graphs
--
David Durst [:ddurst]
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
uspect that if it's too large, we'll be okay with generating the
bytecode on the user's computer.
Cheers,
David
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On Thursday, July 13, 2017 at 1:38:18 PM UTC-7, Joe Hildebrand wrote:
> I'm responding at the top of the thread here so that I'm not singling out any
> particular response.
>
> We didn't make clear in this process how much work Mark and his team did
> ahead of the decision to gather feedback fro
As of bug 1275780, rust panic text gets reported as a MOZ_CRASH reason.
On Mon, Jul 17, 2017 at 12:42 PM, Benjamin Smedberg
wrote:
> I don't know really anything about how rust panics get reflected into
> crash-data. Who would be the right person to talk to about that?
>
> --BDS
>
> On Mon, Jul
plies to builds where add-on signing isn't
required - for builds where it is required, this API is not used at all).
Given all this, the question is do we still need this second API? Does
Thunderbird or SeaMonkey use it for any reason, or can we simplify the
code-base, reduce build size, e
ck of support for
Rust-implemented webidl in m-c, which meant that roughly 50% of the code
I would be writing would have been bug-prone adapters.
Cheers,
David
On 10/07/17 12:29, Nicholas Nethercote wrote:
> Hi,
>
> Firefox now has multiple Rust components, and it's on track to get
Should we moz-prefix moz-specific extensions?
On 25/07/17 20:45, Jet Villegas wrote:
> Based on product plans I've heard, this sounds like the right approach. We
> should try to limit the scope of such browser-specific APIs but it's likely
> necessary in some cases (e.g., in the devtools.)
>
>
>
Well, at least there is the matter of feature detection, for people who
want to write code that will work in more than just Firefox.
moz-prefixing makes it clear that the feature can be absent on some
browsers.
Cheers,
David
On 26/07/17 05:55, Martin Thomson wrote:
> On Wed, Jul 26, 2017 a
Node dependency trees tend to be pretty large, so I'm a little concerned
here. Has the memory footprint be measured?
Cheers,
David
On 31/07/17 19:45, Michael Cooper wrote:
> If you mean using modules from NPM in a browser add-on, the Shield client
> extension recently started
I don't think that anyone deliberately set out to write the code this way.
Likely this is fallout from the mass-refactorings in bug 968520 and related
bugs. I'd recommend working with poiru and froydnj to see if there's any
automated follow-up we could do to remove/improve this pattern.
On Tue, Au
file a bug in PSM:
https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Security%3A%20PSM
Thanks to everyone who made this possible!
Cheers,
David
* the catch is that if any thread needs to query the trust of a
certificate, that thread will block until this operation has completed.
In the worst
s.html# is showing a few
unassigned that are actually assigned (judging from the comments).
Similarly, if something IS assigned to you, but it's not actively being
worked on and you're OK with someone else doing so, please un-assign
yourself.
Thanks...
--
David Durst [:ddurst]
On Tue, Au
Hey, all cool kids have exciting Engineering Newsletters these days, so
it's high time the JavaScript Binary AST got one!
# General idea
JavaScript Binary AST is a joint project between Mozilla and Facebook to
rethink how JavaScript source code is stored/transmitted/parsed. We
expect that this p
Do we know if the other vendors would see value in having this spec'ed
properly so that we have true interop here? Reverse engineering seems like
a "fun" project but what stops people from breaking stuff without realising?
David
On 30 August 2017 at 22:55, Michael Smith wrote:
hread to get this started.
David
On 31 August 2017 at 21:51, Jim Blandy wrote:
> Sorry for the premature send. The complete message should read:
>
> The primary goals here are not related to automation and testing.
>
> - We want to migrate the Devtools console and the JS debug
look weird because symbols are new, but maybe it's just something to
get used to, hard to tell.
David
[1] https://github.com/heycam/webidl/issues/54
[2] https://github.com/heycam/webidl/pull/357
[3] https://github.com/heycam/webidl/issues/419
Le vendredi 1 septembre 2017 17:01:58 UTC+2,
Hi Gabor, I'm interested in shutdown issues. Is there a bug # for this case?
Cheers,
D
On Thu, Sep 21, 2017 at 4:08 AM, Gabor Krizsanits
wrote:
> I guess the question is how do you define "after we've entered shutdown".
>
> For the preallocated process manager both "profile-change-teardown" and
products don't trust any code-signing roots, so this wouldn't work as
before even without removing the now-dead code.
Cheers,
David
On 09/22/2017 01:35 AM, Onno Ekker wrote:
> Op 27-7-2017 om 07:03 schreef Andrew Swan:
>> On Wed, Jul 26, 2017 at 2:49 AM, Frank-Rainer Grahl wrot
I bet Google Benchmark will have what you want.
As a first guess, maybe this?
https://github.com/google/benchmark/blob/master/include/benchmark/benchmark.h#L297
(And if godbolt says they are wrong, please send them a PR :))
On Fri, Oct 6, 2017 at 9:16 AM, Gabriele Svelto wrote:
> On 06/10/201
> On Fri, Oct 6, 2017 at 5:41 PM, David Major wrote:
> > I bet Google Benchmark will have what you want.
> >
> > As a first guess, maybe this?
> > https://github.com/google/benchmark/blob/master/include/
> benchmark/benchmark.h#L297
>
> Thank you. I guess i
taxError is a programmer error.
- Any TypeError is a programmer error.
I expect that this will find a number of lurking errorsy, so we may want
to migrate code progressively, using a directive, say "use strict
moz-platform" and static analysis to help encourage using this directive.
What do
On 18/10/17 10:45, Gregory Szorc wrote:
> I agree that errors like this should have better visibility in order to
> help catch bugs.
>
> I'm not sure changing behavior of the JS VM is the proper layer to
> accomplish this. I think reporting messages from the JS console is a
> better place to sta
, Beta, Release, ...
My main worry, at this stage, is what we encountered when we started
flagging uncaught async errors: some module owners simply never fixed
their errors, so we had to whitelist large swaths of Firefox code,
knowing that it was misbehaving.
Cheers,
David
On 18/10/17 14:16, Boris Zbarsky wrote:
> On 10/18/17 4:28 AM, David Teller wrote:
>> 2/ basically impossible to diagnose in the wild, because there was no
>> error message of any kind.
>
> That's odd. Was the exception caught or something? If not, it should
>
This should be feasible.
Opening bug 1409852 for the low-level support.
On 18/10/17 22:22, Dan Mosedale wrote:
> Could we do this on a per-module opt-in basis to allow for gradual
> migration? That is to say, assuming there's enough information in the
> stack to tell where it was thrown from (I'
Btw, I believe that there is already support for reporting uncaught
errors and that it is blocked by the lack of test harness support.
Cheers,
David
On 18/10/17 19:37, Steve Fink wrote:
> My gut feeling is that you'd only want uncaught errors, and
> AutoJSAPI::ReportException is a b
I'm planning to move production Windows builds to VS2017 (15.4.1) in bug
1408789.
VS2017 has optimizer improvements that produce faster code. I've seen 3-6%
improvement on Speedometer. There is also increased support for C++14 and
C++17 language features:
https://docs.microsoft.com/en-us/cpp/visua
Agreed, changing compilers of an already-released ESR isn't a good idea.
You could use 2017 to build ESR52 locally though, if that's what you're
asking. Our tree has supported 2017 builds for a good while, since it's the
default VS download from Microsoft and a number of Mozillians have been
using
), I'm
comfortable with that number. If it goes longer than that, I agree it makes
sense to wait for a new train.
On Thu, Oct 26, 2017 at 3:31 AM, Sylvestre Ledru wrote:
> Hello,
>
>
> On 25/10/2017 23:48, David Major wrote:
> > I'm planning to move production Windows
rvice, and easily testable on Try. Thank you!
On Wed, Oct 25, 2017 at 5:48 PM, David Major wrote:
> I'm planning to move production Windows builds to VS2017 (15.4.1) in bug
> 1408789.
>
> VS2017 has optimizer improvements that produce faster code. I've seen 3-6%
> improv
ss has only grown in the past X amount of time" or past a certain
threshold, that's the best indicator I've come up with.
I don't know what we'd do at that point -- force killing the content
process sounds severe (though possibly correct) -- or some alert similar to
r performance, so perhaps
we should disallow this?)
Thanks,
David
signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On 11/03/2017 03:34 PM, Robert Helmer wrote:
> On Fri, Nov 3, 2017 at 3:25 PM, David Keeler wrote:
>> [firefox-dev, dev-addons, and the enterprise mailing list cc'd - please
>> direct follow-up discussion to dev-platform]
>>
>> Hello All,
>>
>> As
As a user, I would definitely love to have this.
I wanted to add something like that to about:performance, but at the
time, my impression was that we did not have sufficient platform data on
where allocations come from to provide something convincing.
Cheers,
David
On 02/11/17 15:34, Randell
I use #developers for two things:
1. I prefer to keep my discussions in smaller topic channels, but for my
sanity I also try to keep my channel list small. There is a large set of
people whom I ping roughly once a month and can't be bothered matching
channels with. #developers is my "lowest common
mozbase stuff is already moving to python 3 support but that still means we
need to have web servers and the actual test runners moved over too.
David
On 10 November 2017 at 23:27, Gregory Szorc wrote:
> For reasons outlined at https://bugzilla.mozilla.org/
> show_bug.cgi?id=1388447#
I am not saying it should but if we have a requirement for python 3, we are
also going to have a requirement for py2 to both be available for local
development.
David
On 11 November 2017 at 14:10, Andrew Halberstadt
wrote:
> On Fri, Nov 10, 2017 at 9:44 PM David Burns wrote:
>
>
WDSpec
tests, a subset of Web-Platform Tests used for testing the WebDriver
specification. Testharness.js and reftests in the Web-Platform tests will
still be working as they use Marionette via another means.
Let me know if you have any questions.
David
Answered inline below.
On 21 November 2017 at 19:03, Nicholas Alexander
wrote:
>
>
> On Tue, Nov 21, 2017 at 5:25 AM, David Burns wrote:
>
>> For the next version of geckodriver I am intending that it not ship a
>> Linux
>> 32 bit version of Geckodriver. Cu
need to gather more info.
Thanks,
Jim and David
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Hi Tantek,
I spun this off the rec proposals thread as per your suggestion.
On Thu, Nov 30, 2017 at 8:58 PM, Tantek Çelik
wrote:
> On Thu, Nov 30, 2017 at 4:10 PM, L. David Baron wrote:
>
>
[snip]
> Two things:
>
> 1. Do we have an Intent to Implement / Ship for the full
Hi Jonathan,
On Thu, Nov 30, 2017 at 9:23 PM, Jonathan Kingston wrote:
>
> *Thoughts*
> We should ensure ARIA provides clear justification for any other roles that
> already have HTML representation.
> I'm pretty sceptical of ARIA helping Accessibility. I think there is more
> impact when assist
On Mon, Dec 4, 2017 at 8:58 AM, Axel Hecht wrote:
> Am 04.12.17 um 05:42 schrieb Jet Villegas:
>
>>
>> On Sun, Dec 3, 2017 at 05:15 Axel Hecht > l...@mozilla.com>> wrote:
>>
>> Am 01.12.17 um 16:45 schrieb Justin Wood:
>> > Hey Everyone,
>>
>>
[snip]
I hope we can change that (testing on
es
> APIs for this kinds of cases.
>
The TestDriver work does a lot of this and is currently being worked on and
hopefully will solve this use case. It uses webdriver under the hood to do
the user mimicing.
David
>
>
> -Olli
>
>
>
> or in the workflow that lead to you
That would be great!
On 03/01/18 23:09, Gabriele Svelto wrote:
> TL;DR this is a proposal to refactor the observer service to use a
> machine-generated list of integers for the topics (disguised as enums/JS
> constants) instead of arbitrary strings.
>
_
Pretty complicated in the general case but might be simple in the case
of number overflow.
Also, while we shouldn't depend on the UI in libpref, could we send some
kind of event or observer notification that the UI could use to display
a detailed error message? It would be a shame if Firefox was b
I'll need a license review for a vendored Rust package. Who can perform
these reviews these days?
Thanks,
Yoric
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On 09/03/2018 19:39, Gregory Szorc wrote:
> On Fri, Mar 9, 2018 at 7:28 AM, David Teller <mailto:dtel...@mozilla.com>> wrote:
>
> I'll need a license review for a vendored Rust package. Who can perform
> these reviews these days?
>
>
> We have an
Out of curiosity, why is the read handled by C++ code?
On 12/03/2018 10:38, Nicholas Nethercote wrote:
> I don't know. But libpref's file-reading is done by C++ code, which passes
> a string to the Rust code for parsing.
>
> Nick
> ___
> dev-platform ma
Link xul.dll in 20 seconds with this one weird trick!
Hi everyone,
clang-cl builds of Firefox have come a long way, from being a hobby project
of a few developers to running static analysis in CI for more than a year
now. The tools are in really good shape and should be ready for broader use
wit
SDK version 10.0.16299.0 and later..."
>
> I know that I can set WINDOWSSDKDIR, but I'm not willing to mess too
> much with the env. Is there a bug tracking the update to the latest
> sdk, or automatically use the right one, that I can follow?
>
>
> On Tue, Mar 13, 20
Just noting that there's bug 1399962 right now -- and if you're single core
(like a large portion of very affordable PCs in the past two years or so),
the problem can be so bad (bug 1431835) that common sites like amazon can
turn Firefox into a not viable option.
--
David Durst [:ddurs
# Summary
JavaScript parsing and compilation are performance bottlenecks. The
JavaScript Binary AST is a domain-specific content encoding for
JavaScript, designed to speed up parsing and compilation of JavaScript,
as well as to allow streaming compilation of JavaScript (and possibly
streaming star
ct that it uses a very different path in Necko, which
is the Source of Truth for the Bytecode Cache, but I may be wrong, and
it might be fixable.
Cheers,
David
On 18/04/2018 19:09, Dave Townsend wrote:
> This is awesome. I understand that we already do some kind of
> pre-compile for our chrom
we need to copy the license somewhere in
the test repo, right?
Cheers,
David
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
This sounds like https://bugzilla.mozilla.org/show_bug.cgi?id=1434589
which currently doesn't have a fix. You might be able to work around
it for now with --disable-webrtc.
On Wed, May 2, 2018 at 1:08 PM, Charles G Robertson
wrote:
> Hi,
>
> I'm trying to build Firefox 60 Beta on Arm64 and seeing
We've confirmed that this issue with debug symbols comes from lld-link and
not from clang-cl. This will likely need a fix from the LLVM side, but in
the meantime I'd like to encourage people not to be deterred from using
clang-cl as your compiler.
On Thu, May 10, 2018 at 9:12 PM Xidorn Quan wrote
Bug 1360120 on inbound enables Windows ASan builds and tests on trunk branches.
Initially these are tier-2 while we confirm that this doesn't
introduce test flakiness. If nothing catches fire, I intend to bump
them to tier-1 in the near future.
You can run these jobs on try under the platform nam
As of bug 1467126 these jobs are now running at tier 1.
On Fri, Jun 1, 2018 at 3:16 PM David Major wrote:
>
> Bug 1360120 on inbound enables Windows ASan builds and tests on trunk
> branches.
>
> Initially these are tier-2 while we confirm that this doesn't
> intro
users.
- After that week, we then push RDL to 100% of users.
Please reply if you have any questions or concerns about this plan.
Thanks,
David and Matt
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1467514
___
dev-platform mailing list
dev-platform
Bug 1443590 is switching our official Windows builds to use clang-cl
as the compiler.
Please keep an eye out for regressions and file a blocking bug for
anything that might be fallout from this change. I'm especially
interested in hearing about the quality of the debugging experience.
It's possib
nt us from collecting data on Nightly.
On Tue, Jul 10, 2018 at 4:31 PM Chris Peterson wrote:
>
> How does the performance of clang-cl builds compare to MSVC builds on
> benchmarks like Speedometer?
>
>
> On 2018-07-10 1:29 PM, David Major wrote:
> > Bug 1443590 is switching our of
).
>
How often is this code run? Is there a place to find the daily output of
this tool applied to a nightly build for instance?
Thanks again,
David
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
This touches on a really important point: we're not the only ones
allocating memory.
Just a few that come to mind: GPU drivers, system media codecs, a11y
tools, and especially on Windows we have to deal with "utility"
applications, corporate-mandated gunk, and downright crapware.
When we're measu
Is this pref something that's exposed to users, or is it only
about:config (I can't seem to find any UI for it)?
If so, this seems like a step away from being able to ever expose it as
more apps will be built assuming IndexedDB will be unconditionally
available in 3rd party iframes. This change wo
quot;sooper sekrit" their addon
is. It's in AMO or else...
I honestly thought we would do the "signing keys to developers" approach
and revoke when they are being naughty.
David
[1] http://github.com/seleniumhq/selenium
On 26 November 2015 at 13:50, Thomas Zimmermann
wrote:
Hi,
Just a drive-by comment to inform folks that there is an effort to
transition Mozilla JavaScript codebase to standard JavaScript.
Main bugs is: https://bugzilla.mozilla.org/show_bug.cgi?id=867617
And https://bugzilla.mozilla.org/show_bug.cgi?id=1103158 is about
removing non-standard featu
Well done Sheriffs! Really proud of all the work you did this year!
David
On 30 December 2015 at 14:19, Carsten Book wrote:
> Hi,
>
> Sheriffing is not just about Checkins, Uplifts and Backouts - its also a
> lot of teamwork with different Groups and our Community like Developers
> { "aus5.mozilla.org", true, true, true, 7, &kPinset_mozilla },
Just for clarification and future reference, the second "true" means this
entry is in test mode, so it's not actually enforced by default.
On Mon, Jan 4, 2016 at 1:08 PM, Dave Townsend wrote:
> aus5 (the server the app updater che
You can try getting access to
https://dxr.mozilla.org/mozilla-central/source/testing/marionette/capture.js
and then that will give you everything you want or you can just "borrow"
the code from there.
David
On 19 January 2016 at 11:22, Ted Mielczarek wrote:
> On Tue, Jan 19, 2016
re was also work to see if we can get speed ups by using different
versions of compilers. We are noticing huge gains by upgrading to newer
versions but some of the upgrades require some work before we can deploy
them. When we are looking to do the upgrade we will email the list to warn
you.
David
improvements in build times by switching to
Visual Studio 2015. There are however a few regressions in moving to the
latest version. gps has asked for assistance[5] in helping finalise what we
need to make the move. If you can, help get this over the line!
Regards,
David
[1] https
be:
#include "Foo.h"
#include "bar.h"
or
#include "bar.h"
#include "Foo.h"
Based on the "Java practices" section of that document, I'm assuming
it's the former, but that's just an assumption and in either case it
would
, m4 code, and Makefiles from
mozilla-central. As mentioned in the previous status email, this will allow
us to replace the build backend with a more performant tool.
David
[1]
https://groups.google.com/d/msg/mozilla.dev.platform/IKRdGCjdN_Y/sK2QbXqmCAAJ
[2]
https://treeherder.mozilla.org
1 - 100 of 1097 matches
Mail list logo
