On Monday 2013-06-24 20:08 -0700, Brian Smith wrote:
> These clarifications would greatly help me (and probably owners and peers of
> other modules) scope our participation in this discussion. As far as the DOM
> module is concerned, I am mostly part of the peanut gallery so my judgement
> of wh
On Tue, Jun 25, 2013 at 3:08 PM, Brian Smith wrote:
> At the same time, I doubt such a policy is necessary or helpful for the
> modules that I am owner/peer of (PSM/Necko), at least at this time. In
> fact, though I haven't thought about it deeply, most of the recent evidence
> I've observed indi
Andrew Overholt wrote:
> Back in November, Henri Sivonen started a thread here entitled
> "Proposal: Not shipping prefixed APIs on the release channel" [1]. The
> policy of not shipping moz-prefixed APIs in releases was accepted AFAICT.
>
> I've incorporated that policy into a broader one regardi
Under what circumstances would you expect the code coverage build to break
but all our other builds to remain green?
On Jun 24, 2013 6:51 PM, "Clint Talbert" wrote:
> Decoder and Jcranmer got code coverage working on Try[1]. They'd like to
> expand this into something that runs automatically, gen
Decoder and Jcranmer got code coverage working on Try[1]. They'd like to
expand this into something that runs automatically, generating results
over time so that we can actually know what our code coverage status is
with our major run-on-checkin test harnesses. While both Joduinn and I
are hap
The next MemShrink meeting will be a birthday party:
https://blog.mozilla.org/nnethercote/2013/06/15/memshrinks-2nd-birthday/
The wiki page for this meeting is at:
https://wiki.mozilla.org/Performance/MemShrink
Agenda:
* Prioritize unprioritized MemShrink bugs.
* Discuss how we measure progre
There are two things that I think can use clarification. One is what
we're going to do about "trivial changes"? Do all web facing features
ned to go through this process?
The other question is, what we're going to do about negative feedback
from the API review phase but where the feedback ca
On 2013-06-24 1:50 PM, Kyle Huey wrote:
1. "at least one other browser vendor ships -- or publicly states their
intention to ship -- a compatible implementation of this API"
Because Apple and Microsoft generally do not publicly comment on upcoming
features, and Presto is no more, in practice thi
On Fri, Jun 21, 2013 at 1:45 PM, Andrew Overholt wrote:
> Back in November, Henri Sivonen started a thread here entitled "Proposal:
> Not shipping prefixed APIs on the release channel" [1]. The policy of not
> shipping moz-prefixed APIs in releases was accepted AFAICT.
>
> I've incorporated that
Hi, everyone -
In a little while, the Mozilla Science Lab will be running an experiment, and I
want to know if you'd like to help.
(Some of you are thinking, you had me at Mozilla Science Lab. I know; that's
how they got me, too. Keep reading!)
The gist of it is: This is a pilot program, a
On 21/06/13 05:56 PM, Adam Roach wrote:
On 6/21/13 15:45, Andrew Overholt wrote:
I'd appreciate your review feedback. Thanks.
I'm having a hard time rectifying these two passages, which seem to be
in direct contradiction:
1. "Note that at this time, we are specifically focusing on /new/ JS
On 21/06/13 06:05 PM, Benoit Jacob wrote:
Just to say, WebGL won't have to be an exception after all --- at least
not newer WebGL extensions.
Ah, thanks for letting me know.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.m
On Fri 21 Jun 2013 06:44:08 PM EDT, Robert O'Callahan wrote:
I think "APIs which only Mozilla is interested in at that time" needs
clarification that this refers to APIs that solve use cases that only
Mozilla is interested in. If other vendors are interested in those
use-cases, but don't like our
Meeting Details:
* Agenda: https://etherpad.mozilla.org/webapi-meetingnotes
* WebAPI Vidyo room
* A room we can find, San Francisco office
* Spadina conf. room, Toronto office
* Allo Allo conf. room, London office
* Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL)
* US Vidyo Phone #
14 matches
Mail list logo
