On 2016-03-29 8:09 PM, Eric Rescorla wrote:
On a more substantive, less procedural note, this seems to be designed
for a particular workflow in which there is an assumption that bugs
are for immediate processing. However, in may cases we use bugs as
placeholders or assemble big dependency tre
On Wed, Mar 30, 2016 at 12:41 PM, Xidorn Quan wrote:
> I'd suggest you use https instead, it seems to work with ftp.mozilla.org :)
Indeed. Don't drop the scheme entirely either, since Firefox attempts
to use FTP, which isn't available on that server.
_
On Tue, Mar 29, 2016 at 5:09 PM, Eric Rescorla wrote:
> On a more substantive, less procedural note, this seems to be designed for
> a particular workflow in which there is an assumption that bugs are for
> immediate processing. However, in may cases we use bugs as placeholders or
> assemble big
On Wed, Mar 30, 2016 at 12:30 PM, Ryan VanderMeulen <
rvandermeu...@mozilla.com> wrote:
> I am pleased to announce the final release of MozillaBuild 2.2.0.
>
> http://ftp.mozilla.org/pub/mozilla.org/mozilla/libraries/win32/MozillaBuildSetup-Latest.exe
I'd suggest you use https instead, it seems
I am pleased to announce the final release of MozillaBuild 2.2.0.
http://ftp.mozilla.org/pub/mozilla.org/mozilla/libraries/win32/MozillaBuildSetup-Latest.exe
Important changes since version 2.1.0:
* Updated Mercurial to version 3.7.3.
* Added the optional hgwatchman extension (disabled by default)
Thanks for helping test! Feel free to disable the feature for now since
right now enabling this has been de-prioritize for the time being while we
focus on shipping APZ and E10S.
On Tue, Mar 29, 2016 at 4:55 PM, Jonas Sicking wrote:
> Hi Benoit,
>
> There's two problems that I've seen related to
Hmmm... Who do you believe is the decider here and what do you believe is
the decision procedure for these components? Generally, the way things work
isn't that Firefox promulgates policy for how other components handle their
bugs.
On a more substantive, less procedural note, this seems to be desi
Components that feed into FFx, so that's Core, Toolbox, Firefox, Fennec and
the pieces of platform we're using to ship.
While there's not a 'Gecko' component in bugzilla, it does cover the
components there which are Gecko.
-- Emma
On Tue, Mar 29, 2016 at 3:16 PM, Eric Rescorla wrote:
> I'm try
Thanks for cleaning this stuff up!
On 2016-03-29 2:26 PM, Fernando Jiménez Moreno wrote:
> Hello,
>
> the non-standard Mobile Identity API [1] allows a privileged web application
> to obtain a verified phone number [1]. It is only available on Firefox OS and
> it was added with FxOS Hello clien
I'm trying to figure out the scope of this proposal. Are you expecting it
to apply merely to Firefox or to Gecko as well?
-Ekr
On Tue, Mar 29, 2016 at 1:07 PM, Emma Humphries wrote:
> tl;dr
>
> In Quarter Two I'm implementing the work we’ve been doing to improve
> triage, make actionable decis
For when you are too lazy to type MOZ_ALWAYS_TRUE(NS_SUCCEEDS(foo)).
This was added in bug 1259294, which merged to mozilla-central this morning.
- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-
Hey Jonas,
this second issue that you're seeing is tracked at
https://bugzilla.mozilla.org/show_bug.cgi?id=1257862
Cheers,
Felipe
On Tue, Mar 29, 2016 at 5:55 PM, Jonas Sicking wrote:
> Hi Benoit,
>
> There's two problems that I've seen related to scrolling, and so
> possibly the result of APZ
Hi Benoit,
There's two problems that I've seen related to scrolling, and so
possibly the result of APZ.
The most obvious one is that if the child process is busy doing
things, then the scrollable area seems "sticky". When you start
scrolling there's a noticeable delay before the page starts scrol
This isn't an explicit goal for now, although where this is possible it can
and should be done. When the patches in the bug I mentioned land, support
files appearing alongside individual tests rather than in the DEFAULT
section will result in only the support files for requested tests being
install
Is the goal moving forward to have "support-files" annotations alongside
the test that requires them instead of global to the manifest file?
Will this allow a further optimization of only installing the support-file
for tests are being requested?
Thanks,
Jared
On Tue, Mar 29, 2016 at 12:55 PM, C
tl;dr
In Quarter Two I'm implementing the work we’ve been doing to improve
triage, make actionable decisions on new bugs, and prevent us from shipping
regressions in Firefox.
Today I’m asking for feedback on the plan which is posted at:
https://docs.google.com/document/d/1FFrtS0u6gNBE1mxsGJA9JLs
Hello,
the non-standard Mobile Identity API [1] allows a privileged web application to
obtain a verified phone number [1]. It is only available on Firefox OS and it
was added with FxOS Hello client requirements in mind [2]. Unfortunately, the
FxOS Hello client didn't last long and now according
As you may know, manifestparser test manifests (mochitest.ini, browser.ini
and co.) contain a "support-files" field informing the build system certain
files in the tree or generated at build time are required by tests. These
files are currently installed to the objdir for some test flavors and
inco
18 matches
Mail list logo
