Hi,
good morning.
Since the Trees are still closed here is a update as of 0:45am Pacific Time
* https://bugzilla.mozilla.org/show_bug.cgi?id=932898 has an owner now
* https://bugzilla.mozilla.org/show_bug.cgi?id=932880 Patch landed on inbound
and tests are running.
Cheers,
- Tomcat
- O
On Thursday, October 31, 2013 2:09:06 AM UTC+2, David E. Ross wrote:
> This appears to be a total reversal of past Mozilla philosophy, ...
Agreed. Central repo and mandatory approval is not what Mozilla is IMO. While
there are some gains from such move, I think it hurts freedom and openness more.
With OMTC these days the Layer classes don't hold any logic. All the fancy
stuff goes into classes inheriting from CompositableClient (and
CompositableHost on the compositor side). While Layer classes can only be
manipulated from the main thread and use the PLayerTransaction IPDL
protocol to sync w
Le 13-10-30 17:55, Florian Bender a écrit :
Shouldn't this be posted to m.d.security?
As far as I understood, m.d.security was more targeted at implementing
security standards, not security bugs corrections. But I may be wrong.
___
dev-platform mail
Le 13-10-31 01:12, Jesse Ruderman a écrit :
The three bug reports:
https://bugzilla.mozilla.org/show_bug.cgi?id=823336
https://bugzilla.mozilla.org/show_bug.cgi?id=823338
https://bugzilla.mozilla.org/show_bug.cgi?id=826201
Short and efficient answer. Thanks Jesse!
Do we still run this (and ma
I think it makes a lot of sense to test the spread. +1
- Original Message -
From: Armen Zambrano G.
To: dev-platform@lists.mozilla.org
Sent: Tue, 29 Oct 2013 13:31:33 -0700 (PDT)
Subject: Re: Improving Mac OS X 10.6 test wait times by reducing 10.7 load
Hello all,
I would like to re-visi
On Wednesday, January 9, 2013 11:17:12 AM UTC-6, joshu...@gmail.com wrote:
> I know that there are probably well thought out reasons that this isn't a
> features already...BUT! Lot's of US Government users can't use Firefox
> because it doesn't use the Windows certificate store.
>
>
>
> Would
I'm thinking all new contributors (volunteer or paid) and presented
online as a series of videos (where applicable) with accompanying
documentation.
On Wed 30 Oct 2013 04:14:17 PM EDT, Josh Matthews wrote:
Who is the audience? Where will this information be presented?
On 10/30/2013 02:58 PM,
Since the concern has already been raised on IRC a few times about the
likelihood of bustage pileups once the tree re-opens, I would also like to also
throw out a quick reminder that Try wait times are probably the lowest they
will ever be during a regular week because of this closure, so *pleas
cc Lukas and Mark, who have started looking at onboarding material for new
corporate partners.
We also discussed a similar topic in our Oct monthly epm meetup (last week).
Lukas has initiated a conversation with Amie to see about incorporating similar
material into the employee onboarding expe
On 10/29/2013 4:31 PM, Armen Zambrano G. wrote:
In order to improve our wait times, I propose that we stop testing on
tbpl per-checkin [2] on OS X 10.7 and re-purpose the 10.7 machines as
10.6 to increase our capacity.
Please let us know if this plan is unacceptable and needs further
discussion.
The style guide doesn't seem to address this:
When I have, say, a class in the global namespace called nsSVGUtils, what is
preferred:
class nsSVGUtils
{
public:
// blah blah
static mozilla::gfx::FillRule GetFillRule(mozilla::dom::Element* aElement);
// blah blah
};
or:
class nsSVGU
On Fri, Nov 1, 2013 at 6:27 AM, Jonathan Watt wrote:
> The style guide doesn't seem to address this:
>
> When I have, say, a class in the global namespace called nsSVGUtils, what
> is preferred:
>
> class nsSVGUtils
> {
> public:
>
> // blah blah
>
> static mozilla::gfx::FillRule GetFillRule(
Can we agree on using the using directive instead of typedefs when it comes to
namespaces? I think it's less likely to lead to confusing compile errors than
typedefs.
class nsSVGUtils
{
using mozilla::gfx::FillRule;
using mozilla::dom::Element;
public:
static FillRule GetFillRule(Eleme
On 10/31/13 3:05 PM, Monica Chew wrote:
Can we agree on using the using directive instead of typedefs when it comes to
namespaces? I think it's less likely to lead to confusing compile errors than
typedefs.
class nsSVGUtils
{
using mozilla::gfx::FillRule;
I believe this is not valid C++,
On 31/10/2013 19:05, Monica Chew wrote:
Can we agree on using the using directive instead of typedefs when it comes to
namespaces? I think it's less likely to lead to confusing compile errors than
typedefs.
class nsSVGUtils
{
using mozilla::gfx::FillRule;
using mozilla::dom::Element;
On Thu, Oct 31, 2013 at 11:19 PM, Nicolas Silva wrote:
> With OMTC these days the Layer classes don't hold any logic. All the fancy
> stuff goes into classes inheriting from CompositableClient (and
> CompositableHost on the compositor side). While Layer classes can only be
> manipulated from the m
This compiles using g++ for me.
namespace foo {
namespace bar {
class baz;
}
}
using foo::bar::baz;
class nsSVGUtils
{
public:
static baz GetFillRule(baz* aElement);
};
int main(void) {
return 0;
}
- Original Message -
> On 10/31/13 3:05 PM, Monica Chew wrote:
> > Can we agree on us
On Fri, Nov 1, 2013 at 9:03 AM, Monica Chew wrote:
> This compiles using g++ for me.
>
> namespace foo {
> namespace bar {
> class baz;
> }
> }
>
> using foo::bar::baz;
> class nsSVGUtils
> {
> public:
> static baz GetFillRule(baz* aElement);
> };
>
> int main(void) {
> return 0;
> }
>
If we
Ugh, you're right :( I had originally tested in a class-less function. Within
class declarations "using" is only good for things in the base class.
http://en.cppreference.com/w/cpp/language/using_declaration
- Original Message -
> On Fri, Nov 1, 2013 at 9:03 AM, Monica Chew wrote:
>
>
On Thu, Oct 31, 2013 at 1:55 AM, Avi Hal wrote:
> Essentially the browser has become an operating system, where apps/addons
> could be installed to it, including malwares. However, consider what happens
> if
> Microsoft or Apple would not let any app run unless it's approved on their
> main
> de
I have no idea about construction and resizing, but webgl's frame flinging (and
by extension skia-gl's) should Just Work already.
WebGL content blithely calls SurfaceStream::SwapProducer, and somewhere in
Layers/TextureClient/Host code there's a call to SurfaceStream::SwapConsumer.
The only thing
Started happening recently, though I'm not sure if it's my system or something
changed in our code. Anyone else able to build ASAN debug on OS X? I'm using
clang.
This is what I get:
8:23.40 1.
/Users/msreckovic/Repos/mozilla-asan/widget/cocoa/nsChildView.mm:6175:1:
current parser toke
On Wed, Oct 30, 2013 at 11:04 AM, Ed Morley wrote:
> Hi all!
>
> Trunk trees are currently closed [1] - the requirements for reopening are:
> https://bugzilla.mozilla.org/show_bug.cgi?id=932781#c11
I have (slightly optimistically) started writing a post-mortem of this
closure, analyzing what went
Hi all,
The trees have reopened, based on the fact that the relevant tests are
passing again reliably.
That doesn't mean the work is over. Remaining things I'm aware of:
- Finish fixing the devtools leaks:
https://bugzilla.mozilla.org/show_bug.cgi?id=932880. One patch has
landed, bgrinstead ha
On Thu, Oct 31, 2013 at 6:52 PM, Nicholas Nethercote
wrote:
>
> Remaining things I'm aware of:
One more: lots of patches will need to be backported to Aurora and
Beta. I've set the appropriate tracking flags on the bugs that I
think need it, but please double-check ones you know about in case
I
> I have (slightly optimistically) started writing a post-mortem of this
> closure, analyzing what went wrong and why, and how we might avoid it
> in the future:
>
> https://etherpad.mozilla.org/mEB0H50ZjX
FWIW, I added the following TL;DR to the document, which reflects my
understanding of the
27 matches
Mail list logo
