> Is there sanity to this proposal or am I still crazy?
If we had a lot more project branches, wouldn't that increase the load
on infra dramatically, because we'd have less coalescing?
This is of course a solvable problem, but the fact that the problem
exists suggests to me that your proposal her
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 infrastructure load
> -Changing pushing
The Firefox/Gecko development meeting is held weekly to discuss development
team progress and issues related to the development of Firefox branded products
and the Gecko platform.
Actions from last week are here:
https://wiki.mozilla.org/Platform/2013-04-30#Actions
Meeting Details:
* Agenda: h
Multiple inbounds are not a great idea for smarter usage of our infra
capacity or for load balancing, but this proposal doesn't attempt to
address the former and avoids the latter by making the availability of
the two inbounds mutually exclusive, so, it looks good.
I also doubt that it's going
On 2013-04-29 1:51 PM, Taras Glek wrote:
* How to robustly write/update small datasets?
#3 above is it for small datasets. The correct way to do this is to
write blobs of JSON to disk. End of discussion.
For an API that is meant to be used by add-on authors, I'm afraid the
situation is not as
On Tue, Apr 30, 2013 at 5:32 AM, Kyle Huey wrote:
> Is it feasible to make these functions infallible? What work would need to
> be done?
>
Off the top of my head, I think it probably is feasible. IIRC XPCOM event
dispatch can fail for two reasons: OOM, and when the thread has been shut
down. W
Maybe another route to trial this would be to use our product
announcements feature since it can be much more targeted. I would not be
wholly comfortable at this point to use the snippet real estate (if I was
reading the original request), especially for our GA audience.
I also think we should thi
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 Szorc's Vidyo Room at 1400 PDT Tuesday, April 30.
That's 2200 UTC. Apologies to the European and east coast crowds.
On 4/29/13 11:05 AM, Kyle Huey wrote:
Our (ostensibly) weekly DOM bindings meetings continue on Monday April 29th
at 12:30 PM PDT.
Per discussion of the meeting, here's a strawman plan for converting
Window to WebIDL: https://etherpad.mozilla.org/WebIDL-Window
Please add anything I missed th
Note new meeting time: Tuesday, 30 April 2013, 14:00:00 PDT
Note new Vidyo room: MTV 3V Very Good Very Mighty
The next MemShrink meeting will be brought to you by properly
discarding memory:
https://bugzilla.mozilla.org/show_bug.cgi?id=854799
The wiki page for this meeting is at:
https://wi
On Apr 29, 2013, at 3:07 PM, Chris Peterson wrote:
> (Sorry if this is not the right forum for this discussion.)
dev-planning feels right-er here - I suggest follow ups take it thattaway.
J
PS - original post, for dev-planning context:
> To increase our testing populations, I'd like to sugges
A lot of this has to do with population diversity (as opposed to size) and 3rd
party plugins/add-ons only targeting Beta/Release.
-Alex
On Apr 29, 2013, at 12:26 PM, Kyle Huey wrote:
> On Mon, Apr 29, 2013 at 12:17 PM, Taras Glek wrote:
>
>> What is the problem with current population size?
On Mon, Apr 29, 2013 at 12:17 PM, Taras Glek wrote:
> What is the problem with current population size? We are not as small as
> Android on desktop channels :)
We routinely see serious bugs first on Beta or Release ...
- Kyle
___
dev-platform mailing
What is the problem with current population size? We are not as small as
Android on desktop channels :)
Chris Peterson wrote:
(Sorry if this is not the right forum for this discussion.)
To increase our testing populations, I'd like to suggest that we add a
periodic "channel upsell" message to
(Sorry if this is not the right forum for this discussion.)
To increase our testing populations, I'd like to suggest that we add a
periodic "channel upsell" message to the about:home page (of Aurora and
Beta) and the about box (of Aurora, Beta, and possibly Release).
Beta and Aurora users hav
On 4/26/2013 1:17 PM, Gregory Szorc wrote:
I'd like to start a discussion about the state of storage in Gecko.
Currently when you are writing a feature that needs to store data, you
have roughly 3 choices:
1) Preferences
2) SQLite
3) Manual file I/O
One of the ongoing tasks I dabbled in was r
Andreas Gal wrote:
Preferences are as the name implies intended for preferences. There is no sane
use case for storing data in preferences. I would give any patch I come across
doing that an automatic sr- for poor taste and general insanity.
SQLite is definitely not cheap, and we should look
On 4/29/13 1:57 PM, Andrew McCreight wrote:
A WebIDL callback interface thing could probably be set up to make calling from
C++ into JS less awful, if somebody has a need.
Sort of. IndexedDB keys are done on raw JS values ("any" in the IDL)
because they want to tell apart Arrays from other o
- Original Message -
> On Apr 27, 9:37 am, Mounir Lamouri wrote:
> > Why? Wouldn't be the idea of such component to make sure it is
> > usable
> > from C++?
>
> Perhaps some day, but IndexedDB was always designed with JS in mind.
> To use it you pass special JS dictionaries for options, c
So there is no general 'good for performance' way of doing IO.
However I think most people who need this need to write small bits of
data and there is a good way to do that.
Gregory Szorc wrote:
I'd like to start a discussion about the state of storage in Gecko.
Currently when you are writi
Is it feasible to make these functions infallible? What work would need to
be done?
- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On Apr 27, 9:37 am, Mounir Lamouri wrote:
> Why? Wouldn't be the idea of such component to make sure it is usable
> from C++?
Perhaps some day, but IndexedDB was always designed with JS in mind.
To use it you pass special JS dictionaries for options, clone things
to/from JS objects, etc. Using it
Our (ostensibly) weekly DOM bindings meetings continue on Monday April 29th
at 12:30 PM PDT.
Meeting details:
* Monday, April 29, 2013, 12:30 PM PDT (3:30 PM EDT/9:30 PM CEST)
* Dial-in Info:
- Vidyo room: Boris Zbarsky
- In office or soft phone: extension 92
- US/INTL: 650-903-0800 or 650-215
Meeting Details:
* Agenda: https://wiki.mozilla.org/WebAPI/2013-04-30
* WebAPI Vidyo room
* Amoeba conf. room, San Francisco office (7A)
* 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 # 1
On 4/29/2013 9:32 AM, Boris Zbarsky wrote:
On 4/26/13 6:26 PM, Nicholas Nethercote wrote:
If I have a patch ready to land when inbound closes, what would be the
sequence of steps that I need to do to land it on inbound2?
The following steps assume that the default and default-push for your
re
On 4/27/2013 6:26 PM, al...@yahoo.com wrote:
... appear to be possible without the \ escape. In fact the \ can not be
present as it does not escape the newline but becomes a part of the string.
Once upon a time, prefs files were actually JS: we created a function
"pref" and "user_pref" and then
On 4/26/13 6:26 PM, Nicholas Nethercote wrote:
If I have a patch ready to land when inbound closes, what would be the
sequence of steps that I need to do to land it on inbound2?
The following steps assume that the default and default-push for your
repo are both appropriate versions of inbound
27 matches
Mail list logo
