Re: packaged apps and origins

On Fri, Apr 26, 2013 at 1:34 AM, Ben Adida wrote: > Currently, packaged apps run in an origin that is newly minted for each > device installation, effectively a GUID that differs from device to device. > This works up until the point where the rest of the Web expects a stable > origin across devic

EOL of XP = EOL of GDI?

Greetings, it might be a little bit early considering that XP hasn't reached its EOL yet and probably even then will be far from being out-of-favor enough, but I was wondering whether once the time has come it's also time to move away from all GDI code paths concerning font rendering on Windows

Re: Improving Mac OS X 10.6 test wait times by reducing 10.7 load

On Thursday, April 25, 2013 4:12:16 PM UTC-4, Ed Morley wrote: > On 25 April 2013 20:14:10, Justin Lebar wrote: > > >> Is this what you're saying? > > >> * 10.6 opt tests - per-checkin (no change) > > >> * 10.6 debug tests- reduced > > >> * 10.7 opt tests - reduced > > >> *

Re: packaged apps and origins

On 4/26/13 3:02 AM, Anne van Kesteren wrote: What is origin used for? Can Persona not use object-capabilities instead? Do you mean that we should completely revamp the Persona protocol, including assertions to an origin and the way we present the login UI to users, because packaged apps don'

Re: packaged apps and origins

On Fri, Apr 26, 2013 at 2:33 PM, Ben Adida wrote: > On 4/26/13 3:02 AM, Anne van Kesteren wrote: >> What is origin used for? Can Persona not use object-capabilities instead? > > Do you mean that we should completely revamp the Persona protocol, including > assertions to an origin and the way we pr

Re: Improving Mac OS X 10.6 test wait times by reducing 10.7 load

On 2013-04-26 9:10 AM, jmaher wrote: On Thursday, April 25, 2013 4:12:16 PM UTC-4, Ed Morley wrote: On 25 April 2013 20:14:10, Justin Lebar wrote: Is this what you're saying? * 10.6 opt tests - per-checkin (no change) * 10.6 debug tests- reduced * 10.7 opt tests -

Re: Improving Mac OS X 10.6 test wait times by reducing 10.7 load

On Friday, April 26, 2013 9:49:18 AM UTC-4, Armen Zambrano G. wrote: > > Maybe we can keep one of the talos jobs around? (until releng fixes the > > various python versions' story) > > IIUC this was more of an infra issue rather than a Firefox testing issue. It was infra related, but it was sp

Re: Improving Mac OS X 10.6 test wait times by reducing 10.7 load

On 4/25/13 1:12 PM, Ed Morley wrote: > On 25 April 2013 20:14:10, Justin Lebar wrote: >>> Is this what you're saying? >>> * 10.6 opt tests - per-checkin (no change) >>> * 10.6 debug tests- reduced >>> * 10.7 opt tests - reduced >>> * 10.7 debug tests - reduced >>> >>> * redu

Re: Some data on mozilla-inbound

On 4/25/13 4:47 PM, Wesley Johnston wrote: > Requesting one set of tests on one platform is a 6-10 hour turnaround for me. That's surprising. https://tbpl.mozilla.org/?tree=Try&rev=9d1daf69061d was a midday -b do -p all -u all with a 3 hour 40 minute end-to-end. Or did you mean, as a great many p

Re: Improving Mac OS X 10.6 test wait times by reducing 10.7 load

> So what we're saying is that we are going to completely reverse our > previous tree management policy? Basically, yes. Although, due to coalescing, do you always have a full run of tests on the tip of m-i before merging to m-c? A better solution would be to let you trigger a full set of tests

Re: Improving Mac OS X 10.6 test wait times by reducing 10.7 load

On 4/26/2013 11:11 AM, Justin Lebar wrote: So what we're saying is that we are going to completely reverse our previous tree management policy? Basically, yes. Although, due to coalescing, do you always have a full run of tests on the tip of m-i before merging to m-c? Yes. Note that we gene

Re: Some data on mozilla-inbound

Maybe. I started to avoid it if possible around then, but almost 4 hours for results still is basically unusable. - Wes - Original Message - From: "Phil Ringnalda" To: dev-platform@lists.mozilla.org Sent: Friday, April 26, 2013 8:01:25 AM Subject: Re: Some data on mozilla-inbound On 4/

Re: Improving Mac OS X 10.6 test wait times by reducing 10.7 load

As a compromise, how hard would it be to run the Mac 10.6 and 10.7 tests on m-i occasionally, like we run the PGO tests? (Maybe we could trigger them on the same csets as we run PGO; it seems like that would be useful.) On Fri, Apr 26, 2013 at 11:19 AM, Ryan VanderMeulen wrote: > On 4/26/2013 11

Re: Some data on mozilla-inbound

On 4/26/13 8:25 AM, Wesley Johnston wrote: > Maybe. I started to avoid it if possible around then, but almost 4 hours for > results still is basically unusable. Tell me about it - that's actually the same as the end-to-end on inbound/central. Unfortunately, engineering is totally indifferent to t

Re: Improving Mac OS X 10.6 test wait times by reducing 10.7 load

On 4/26/13 8:11 AM, Justin Lebar wrote: >> So what we're saying is that we are going to completely reverse our >> previous tree management policy? > > Basically, yes. > > Although, due to coalescing, do you always have a full run of tests on > the tip of m-i before merging to m-c? It's not just

Re: Improving Mac OS X 10.6 test wait times by reducing 10.7 load

Would we be able to go back to where we disabled 10.7 altogether? Product (Asa in separate thread) and release drivers (Akeybl) were OK to the compromise of version specific test coverage being removed completely. Side note: adding Mac PGO would increase the build load (Besides this we have to

Re: Improving Mac OS X 10.6 test wait times by reducing 10.7 load

Just disabling debug and talos jobs for 10.7 should reduce more than 50% of the load on 10.7. That might be sufficient for now. Any objections on this plan? We can re-visit later on if we need more disabled. cheers, Armen On 2013-04-26 11:50 AM, Armen Zambrano G. wrote: Would we be able to go

Re: Improving Mac OS X 10.6 test wait times by reducing 10.7 load

> Would we be able to go back to where we disabled 10.7 altogether? On m-i and try only, or everywhere? On Fri, Apr 26, 2013 at 12:10 PM, Armen Zambrano G. wrote: > Just disabling debug and talos jobs for 10.7 should reduce more than 50% of > the load on 10.7. That might be sufficient for now. >

Re: packaged apps and origins

On 4/25/13 10:34 PM, jsmith.mozi...@gmail.com wrote: 1. It's way too late for this work for v1.01 (i.e. v1.01 OOS) I want to emphasize that the current architecture is not just inconvenient, it breaks a ton of things, including all login solutions for packaged apps. This is a major problem

Re: Automatic tree clobbering is coming

Auto clobber is now opt in on mozilla-central. You will need to add |mk_add_options AUTOCLOBBER=1| to your mozconfig to enable auto clobber. The in-tree mozconfigs (used by automation and possibly some developers) have auto clobber enabled. Thank you for the patch, Ed Morley! On 4/17/2013 4:12 P

Re: Improving Mac OS X 10.6 test wait times by reducing 10.7 load

On 2013-04-26 12:14 PM, Justin Lebar wrote: Would we be able to go back to where we disabled 10.7 altogether? On m-i and try only, or everywhere? The initial proposal was for disabling everywhere. We could leave 10.7 opt jobs running everywhere as a compromise and re-visit after I re-purpo

Re: packaged apps and origins

On Fri, 26 Apr 2013 09:31:30 -0700, Ben Adida wrote: >> 3. I recall talking with Fabrice that this was a non-trivial amount of >> work for fixing this, > > I'm having trouble seeing how that is. We can stage the feature in a > couple of ways, first by letting marketplace packaged apps claim an >

Re: Improving Mac OS X 10.6 test wait times by reducing 10.7 load

I don't think I'm comfortable disabling this platform across the board, or even disabling debug-only runs across the board. As jmaher pointed out, there are platform differences here. If we disable this platform entirely, we lose visibility into rare but, we seem to believe, possible events. It

Storage in Gecko

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 Preferences are arguably the easiest. However, they have a number of setbacks: a) Poor d

Re: Storage in Gecko

On Fri, Apr 26, 2013 at 11:17 AM, 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 > > Preferences are

Re: Improving Mac OS X 10.6 test wait times by reducing 10.7 load

On 2013-04-26 1:31 PM, Justin Lebar wrote: I don't think I'm comfortable disabling this platform across the board, or even disabling debug-only runs across the board. As jmaher pointed out, there are platform differences here. If we disable this platform entirely, we lose visibility into rare b

Re: Storage in Gecko

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 at more suitable back

Re: Improving Mac OS X 10.6 test wait times by reducing 10.7 load

After re-reading, I'm happy to disable just m-i/try for now. Modifying to trigger *some* jobs on m-i through would be some decent amount of work (adding Mac pgo builders) but still different than normal operations and increase the 10.6/10.8 test load. On 2013-04-26 1:31 PM, Justin Lebar wrote

Re: Improving Mac OS X 10.6 test wait times by reducing 10.7 load

I'd be happy if we did the 10.7 and 10.6 tests only when we trigger Windows PGO builds. That seems like a good compromise here, since the sheriffs have to wait for PGO coverage on m-i before merging anyway. On Fri, Apr 26, 2013 at 2:34 PM, Armen Zambrano G. wrote: > After re-reading, I'm happy t

Re: Storage in Gecko

On 4/26/2013 11:26 AM, Kyle Huey wrote: > On Fri, Apr 26, 2013 at 11:17 AM, 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

Re: Storage in Gecko

On Fri, Apr 26, 2013 at 11:36 AM, 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. As Greg sugge

Re: Storage in Gecko

On Fri, Apr 26, 2013 at 11:43 AM, Gregory Szorc wrote: > On 4/26/2013 11:26 AM, Kyle Huey wrote: > > On Fri, Apr 26, 2013 at 11:17 AM, 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

Re: Storage in Gecko

On 4/26/2013 2:52 PM, Kyle Huey wrote: Yeah that's not accurate. It's pretty solid now. It's the storage backend for everything in b2g for instance ... and it's not going to see any changes that aren't backwards compatible. Is IndexedDB ready for use by internal Gecko consumers, including a

Re: Storage in Gecko

> The current level of flakiness in the IndexedDB test suite (especially on > OSX) makes me concerned about what to expect if it starts getting heavier > use across the various platforms. Is that just in the OOP tests, or everywhere? ___ dev-platform mai

Re: Storage in Gecko

On 4/26/2013 2:50 PM, Gavin Sharp wrote: On Fri, Apr 26, 2013 at 11:36 AM, 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 tast

Re: Storage in Gecko

Resending to list. On Fri, Apr 26, 2013 at 12:02 PM, Gregory Szorc wrote: > On 4/26/2013 11:52 AM, Kyle Huey wrote: > > Could you please point me at a "good" implementation of a Gecko consumer > of IndexedDB? If you don't know which are good, an MXR search URL will > suffice :) > I haven't look

Re: Storage in Gecko

On Fri, Apr 26, 2013 at 11:57 AM, Ryan VanderMeulen wrote: > The current level of flakiness in the IndexedDB test suite (especially on > OSX) makes me concerned about what to expect if it starts getting heavier > use across the various platforms. Of the 24 open intermittent failure bugs in the I

Re: Storage in Gecko

On 4/26/2013 3:07 PM, Justin Lebar wrote: The current level of flakiness in the IndexedDB test suite (especially on OSX) makes me concerned about what to expect if it starts getting heavier use across the various platforms. Is that just in the OOP tests, or everywhere? Mostly IPC. __

Proposal for an inbound2 branch

As has been discussed at length in the various infrastructure meetings, one common point of frustration for developers is frequent tree closures due to bustage on inbound. While there are other issues and ideas for how to improve the inbound bustage situation, one problem I'm seeing is that mul

Re: Storage in Gecko

On Fri, Apr 26, 2013 at 8:17 PM, Gregory Szorc wrote: > Anyway, I just wanted to see if others have thought about this. Do > others feel it is a concern? If so, can we formulate a plan to address > it? Who would own this? AIUI the Performance team is experimenting with moving things into JSON fil

Re: Proposal for an inbound2 branch

I like that inbound2 would be open only when inbound is closed. That way you don't have to make a decision wrt which tree to push to. sgtm. On Fri, Apr 26, 2013 at 3:17 PM, Ryan VanderMeulen wrote: > As has been discussed at length in the various infrastructure meetings, one > common point of f

Re: Storage in Gecko

On Fri, Apr 26, 2013 at 12:10 PM, Benjamin Smedberg wrote: > I really hope the outcome of this discussion is that we end up storing > everything that isn't a true preference in some other datastore, and that is > an async-by-default datastore ;-) > With a pretty simple JSM wrapper, indexeddb coul

Re: Storage in Gecko

On 4/26/2013 12:10 PM, Benjamin Smedberg wrote: > On 4/26/2013 2:50 PM, Gavin Sharp wrote: >> On Fri, Apr 26, 2013 at 11:36 AM, 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 p

Re: Storage in Gecko

We use IndexedDB extensively in a lot of the WebAPIs, see Contacts, Settings, SMS, MMS, Push, NetworkStats… Right now there's a lot of boilerplate[1] involved in setting up IndexedDB, and people end up duplicating a lot of the boilerplate code. It'd be great to see a more polished wrapper aroun

Re: Storage in Gecko

On 04/26/2013 03:21 PM, Dirkjan Ochtman wrote: Also, I wonder if SQLite 4 (which is more like a key-value store) SQLite 4 is not actually more like a key-value store. The underlying storage model used by the SQL-interface-that-is-the-interface changed from being a page-centric btree structur

Re: Storage in Gecko

On 04/26/2013 03:30 PM, Gregory Szorc wrote: However, before that happens, I'd like some consensus that IndexedDB is the best solution here. I'd especially like to hear what Performance thinks: I don't want to start creating a "preferred" storage solution without their blessing. If they have sugg

New mfbt header: mozilla/PodOperations.h

For anyone who's not reading planet (or hasn't read it in the last fifteen minutes ;-) ), I recently landed a new mfbt header that exposes slightly safer versions of memset(.., 0, ...), memcpy, and memcmp for use on C++ types, particularly ones where sizeof(T) > 1. http://mxr.mozilla.org/mozill

Re: Some data on mozilla-inbound

On 13-04-26 11:37 , Phil Ringnalda wrote: Unfortunately, engineering is totally indifferent to things like having doubled the cycle time for Win debug browser-chrome since last November. Is there a bug filed for this? I just cranked some of the build.json files through some scripts and got t

Re: Some data on mozilla-inbound

Bug 864085 On Fri, Apr 26, 2013 at 2:06 PM, Kartikaya Gupta wrote: > On 13-04-26 11:37 , Phil Ringnalda wrote: >> >> Unfortunately, engineering is totally indifferent to >> things like having doubled the cycle time for Win debug browser-chrome >> since last November. >> > > Is there a bug filed

Re: Proposal for an inbound2 branch

My only concern with this is that it increases the difficulty of bisecting regressions. Lately I've run into this a few times, where I see regressions on areweslimyet.com and dig into it, only to find the regression happened on a "merge from m-c" changeset. Since the mobile AWSY only runs on m

Re: Some data on mozilla-inbound

On 4/26/2013 2:06 PM, Kartikaya Gupta wrote: > On 13-04-26 11:37 , Phil Ringnalda wrote: >> Unfortunately, engineering is totally indifferent to >> things like having doubled the cycle time for Win debug browser-chrome >> since last November. >> > > Is there a bug filed for this? I just cranked so

Re: Storage in Gecko

On 4/26/13 11:17 AM, Gregory Szorc wrote: But, please don't make consumers worry about things like SQL, schema design, and PRAGMA statements. Ideally, yes. But I suspect there will never be a one-size-fits all solution, and so we should probably be clear about what it's appropriate/intended

Re: Proposal for an inbound2 branch

On Fri, Apr 26, 2013 at 2:16 PM, Kartikaya Gupta wrote: > Lately I've run into this a few times, where I see regressions on > areweslimyet.com and dig into it, only to find the regression happened on a > "merge from m-c" changeset. Since the mobile AWSY only runs on m-i (on the > theory that I get

Re: Proposal for an inbound2 branch

On Sat, Apr 27, 2013 at 5:17 AM, Ryan VanderMeulen wrote: > > -In the event of a long tree closure, the last green changeset from m-i will > be merged to inbound2 and inbound2 will be opened for checkins. If I have a patch ready to land when inbound closes, what would be the sequence of steps tha

Re: Storage in Gecko

I have to admit; I've been thinking about this as well… and considering the complexities involved with developing algorithms to deal with caches, fsyncs and concurrency I tend to lean toward NOT rolling your own, but instead look at what's out there. Event though it's oriented towards server us

Re: Proposal for an inbound2 branch

hi RyanVM; I really like this proposal because it gives Mozilla a way for developers to continue doing checkins even during a prolonged mozilla-inbound closure. The experiment with birch as "b2g-inbound" has been really successful so far, which is good. To easily experiment to see if the proposal

Re: Storage in Gecko

On 26/04/13 11:17, Gregory Szorc wrote: > Anyway, I just wanted to see if others have thought about this. Do > others feel it is a concern? If so, can we formulate a plan to address > it? Who would own this? As others, I believe that we should use IndexedDB for Gecko internal storage. I opened a b

Re: Proposal for an inbound2 branch

> 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? Would I > need to have an up-to-date inbound2 clone and transplant the patch > across? Yes, I think so. I think mbrubeck or someone knows how to maintain multipl

Re: packaged apps and origins

On 25/04/13 17:34, Ben Adida wrote: > Potch has a great proposal: let apps declare a marketplace in their > manifest. If apps are served from and signed by the marketplace, then > any origin is okay (after review.) If apps are self-hosted, then the > only origin allowed is that of the hosting site.

Re: Improving Mac OS X 10.6 test wait times by reducing 10.7 load

On 4/26/2013 9:10 AM, Armen Zambrano G. wrote: Just disabling debug and talos jobs for 10.7 should reduce more than 50% of the load on 10.7. That might be sufficient for now. I'd be happy for us to disable all Talos jobs on 10.7, on all trees. I've been keeping track of Talos stuff recently an

Re: Storage in Gecko

We filed a bug for this and I am working on the patch. Andreas Sent from Mobile. On Apr 26, 2013, at 16:06, Mounir Lamouri wrote: > On 26/04/13 11:17, Gregory Szorc wrote: >> Anyway, I just wanted to see if others have thought about this. Do >> others feel it is a concern? If so, can we formul

Re: Storage in Gecko

Gregory Szorc wrote: c) I/O is synchronous. To be fair, the pref API is mostly reading and writing a big hashtable; few functions actually do any I/O. e) The API is awkward. Well, XPCOM was all the rage at the time. (Then again, so was RDF, and its dynamic bulk read API is still better

Re: Some data on mozilla-inbound

On 14:29, Fri, 26 Apr, Gregory Szorc wrote: On 4/26/2013 2:06 PM, Kartikaya Gupta wrote: On 13-04-26 11:37 , Phil Ringnalda wrote: Unfortunately, engineering is totally indifferent to things like having doubled the cycle time for Win debug browser-chrome since last November. Is there a bug

Re: Proposal for an inbound2 branch

On 4/26/2013 4:14 PM, Justin Lebar 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? Would I >> need to have an up-to-date inbound2 clone and transplant the patch >> across? > Yes, I think so. > > I think

"Experimental Technology" in Gecko (Re: Storage in Gecko)

On 4/26/2013 11:43 AM, Gregory Szorc wrote: Have you explored using IndexedDB? Not seriously. The "this is an experimental technology" warning on MDN is off-putting. The largest audience for MDN is web developers, so we put that warning on anything that's not ready for widespread use on the

Re: Proposal for an inbound2 branch

On 4/26/2013 4:14 PM, Justin Lebar 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? Would I need to have an up-to-date inbound2 clone and transplant the patch across? I think mbrubeck or someone knows how

Re: Storage in Gecko

IndexedDB is our answer for this for JS... C++ folks are still pretty much on their own! IndexedDB handles indexing (hence the rather awkward name), transactions with abort/rollback, object-graph serialization (not just JSON), usage from multiple tabs/windows/components/processes simultaneously, d

Re: Proposal for an inbound2 branch

On 04/26/2013 06:11 PM, Matt Brubeck wrote: On 4/26/2013 4:14 PM, Justin Lebar 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? Would I need to have an up-to-date inbound2 clone and transplant the patch acr