Labs/Jetpack/Weekly Meeting/2011-08-30
From MozillaWiki
< Labs | Jetpack | Weekly Meeting
Contents
Agenda
- FlightDeck Updates
- SDK 1.1 Status
- Bugs Update
- Wes: We need to talk about the Async I/O bug. It could introduce API-breaking changes.
- Wes: Did bug 659478 get forgotten/fixed?
- Roundtable
- Wes: I moved my bug dashboard out of its Jetpack wrapper and into an actual webpage.
- It does more stuff now.
- Next up on my list of things to do is bring back the "staleness" filters (to find bugs that haven't been touched in a while).
- Issue tracker on github if you want to file a request!
- myk: whether or not to land bug 679479 for SDK 1.1
- myk: recording meeting attendees
- Wes: I moved my bug dashboard out of its Jetpack wrapper and into an actual webpage.
Attendees
- mossop
- myk
- gabor
- brian
- jeff
- matteo
- dietrich
- alex
- irakli
- dbuc
- jacob applebaum (dherman)
- wes
Minutes
SDK 1.1 Status
- myk: spinning rc1 today, in two weeks we release 1.1
- matteo: what time today will you spin rc1?
- myk: no particular time, could be anytime PT, including 00:01 (i.e. in the past)!
- myk: does anything still need to land?
- matteo: bug 581982 selection fixes
- myk: seems pretty late for 1.1, can it be 1.2?
- matteo: it can, would like to get it into 1.1 if possible
- myk: land it on development branch for 1.2, then ping me and mossop, and we'll consider it for 1.1
- matteo: can i ping you on IRC?
- myk: indubitably!
whether or not to land bug 679479 for SDK 1.1
- myk: context is that will wrote doc a few weeks ago, alex reviewed and found issues, so r-, then will went on PTO and hasn't updated patch
- jeff and alex conversed recently and agreed that patch is still better than current state
- i am skeptical because it's late for 1.1, the patch is large, and it doesn't have review
- mossop is also skeptical
- jeff: understand about timing
- once i looked at the patch, i realized the info there would be very beneficial to people getting started with the SDK
- people that read the 1.1 docs for the next six weeks will still have a difficult time with this issue
- if we land the patch, that will mitigate things
- but if we don't land the patch, and i do a blog post, that may mitigate things as well
- i'm totally willing to move this week on taking will's edits and putting them into a blog post
- mossop: what's the risk?
- myk: relatively low, no functionality changes, just docs enhancements
- brian: links between docs might break
- mossop: i'm leaning against taking it
- we have policy of landing docs enhancements first two weeks of stabilization cycle
- brian: anything horribly wrong in current docs?
- jeff: the patch explains the realities of running code in content scripts much more clearly
- brian: it's a frequent support topic, i just answered a question on the forum yesterday
- myk: still leaning against taking it
- mossop: we'll skip it for 1.1
- myk: but let's make sure we get the patch in early for 1.2
- have someone else pick it up and run with it while will is away, like jeff
testing repacks
- myk: we need to start testing repacks
- myk: this is the first time we're repacking addons
- this experience will be the first impression
- if we do a bad job, it'll leave a sour taste in developers' mouths
- and make it hard for us to do future repacks
- if we do a good job, it'll be easier to do them in the future
- and expand them to other areas, like localization
- dbuc: i already talked to the AMO folks
- i wrote copy for email message to developers, almost ready
- AMO folks are ready to start testing
- dbuc: we need to have a sample addon to test
- myk: we need to test repacking the actual addons on AMO
- sample addons are simple, don't use many features
- actual addons will use more features
- and they might modify core API implementations, and we need to make sure we deal with that correctly
- brian: i want to know more about how repacking works, can you point me at its code?
- dbuc to point brian at repacking code
- mossop: we should also set up a meeting to plan the repack process
- mossop to set up meeting w/self, myk, dbuc, and an AMO rep
FlightDeck Updates
- dbuc: got filter landed to show how many times a library is being used by addons
- still plugging along on other search facets, should accomplish goal of implementing high-value facets we previously identified
- piotr has implemented first version of feature for pushing addons to AMO
- there'll be a place in the dashboard where you can select which version of an addon you want to push to AMO
- it should be landing within the next couple of weeks
- myk: when are ship dates?
- dbuc: moving to weekly, so tomorrow, and then every Wednesday thereafter
Bugs Update
- wes: status of bug 659478 is unclear; did a fix land?
- myk: no, but we didn't block on it because the problem is intermittent
- i haven't seen it in a while
- mossop: let's unset priority and retriage in regular triage meeting
- wes: a lot of activity with async IO stuff in bug 649889
- folks want file module to use async IO instead of synchronous stuff
- i tried making a patch to do this in file module, then changed simple-storage to use new API
- simple-storage seems to work without its own API changes
- irakli: module loader loads files synchronously
- brian: does seem like a feature page
- mossop: i'm ok with leaving the bug open if that's what platform folks want to use
- myk: me too, although i would prefer a feature page
- mossop: wes, are you just concerned about breaking changes on low-level APIs?
- wes: no, just that the low-level changes have potential to break high-level APIs
- mossop: answer is to get bugs filed on individual cases, figure out which are going to break APIs, work from there
- wes: adding async now can be done easily, then add warnings on sync and eventually cut it out
- mossop: don't see a problem with doing this
- irakli: we use file API a lot for doing synchronous IO
- brian: asynchronicity is contagious
- mossop: are our high-level APIs able to cope?
- brian: it would be nice if we have a coherent story
- mossop: looks like philikon is willing to help us
- mossop: shall someone figure out how this impacts the high-level APIs?
- irakli: i think it's a big change and we should defer it until after e10s
- mossop: could you do a quick sweep?
- irakli: i can do that and start an etherpad page
- myk: perhaps philikon can do some heavy lifting
- but also, this is an API design decision
- we previously designed synchronous high-level APIs intentionally, because we think they're easier for inexperienced developers
- i still think that's the right call, but i'm open to alternatives
- wes: looked at code in Sync project, they have sync-async stuff
- mossop: yeah, but they're getting rid of it, it spins event loop, lots of problems there
- irakli: if we end up with content processes, we'll be able to do synchronous IO in the separate process
- myk: yes, i think philikon has a problem with that as well, i don't yet, but he can make his case
- irakli: most sync is module loading; once we stop unpacking addons, it'll be one operation for jar file
- brian: are you sure?
- mossop: it memory-maps the file
- irakli: omnijar reduces IO operations
- brian: i think it reduces the number of files open to one, not sure about IO operations
Roundtable
Wes's Bug Dashboard Update
- wes: I moved my bug dashboard out of its Jetpack wrapper and into an actual webpage.
- It does more stuff now.
- if you uncheck boxes it's faster
- draws a pie chart
- you can pass parameters to the page through the URL
- brian: there's more to it than the pie chart?
- wes: yes, it just takes a little while to load the additional info
- brian: perhaps add a spinner
- mossop: looks really awesome
- wes: you can pass in specific milestone
- if you want all open bugs, set milestone: all, then uncheck the "include resolved bugs" box and press "Get Bugs"
- brian: when do bugs for the current milestone get retriaged?
- mossop: we did a triage recently, were going to do another, but myk got sick
- mossop: we've scheduled another three hour triage session this thursday
- wes: Next up on my list of things to do is bring back the "staleness" filters (to find bugs that haven't been touched in a while).
- Issue tracker on github if you want to file a request!
Recording Meeting Attendees
- myk: was thinking of starting to record list of meeting attendees
- this is common at meetings without too many people
- useful for posteriority, to remember who was there, and to remember who to ask to review minutes
dherman things
- dherman: couple bugs i noticed recently and wanted to chat about
- my intern rezwana pointed out that Cu.Sandbox forces you to have certain things in scope by default
- in fact, Components global is non-configurable, you can't eliminate it
- we have this principals mechanism that somewhat attentuates Components' power
- better approach would be to only give references to things sandbox should have access to
- went to source and started talking to mrbkap
- he thinks it should be possible to have an option that turns off access to Components
- there are some asserts inside engine that claim components is always there
- can't find code that actually depends on those asserts
- it seems like that's the cleanest approach
- rather than messing with principals, which are pretty broken to begin with
- but i haven't looked at the bug that gabor linked to yet
- so i figured i should talk with you guys to see what is best approach
- if you already have it covered, no worries
- mossop: what bug?
- someone: bug 682167
- brian: i want each module to have separate primordials and no components unless turned on statically
- there are a bunch of ways to accomplish that
- dherman: it might be nice to give finer-grained access than just Components or not
- brian: yes, would be interesting to explore
- dherman: other half, perhaps separate convo
- when we were looking into require("chrome"), we got nervous that since addon author is running cuddlefish offline, any static guarantees...
- brian: we're not relying on authors' machine to do checks, they're all done down the road
- dherman: apologize if i'm bringing up old stuff
- dherman: consider possibility of having cuddlefish on server so you can make static guarantees from generation process?
- brian: i can't speak for AMO, my perspective is that once it shows up on AMO, we pass it through analyzer
- it presents info to reviewers based on statically-generated manifest
- dherman: one difference is you could make some things correct by construction
- brian: that's the intention, the way to implement is to have sandboxes without Components unless runtime loader sets flag
- AMO can then check hash of loader file to know it'll honor the manifest
- brian: there's nothing that author can do to sneak around loader as long as we verify the loader by its hash
- mossop: sounds like we should have another meeting to address this specifically
- brian to set up meeting
- alex: quick comment about principals
- it's quite important to have a low-privilege principal to apply to sandboxes that don't require("chrome")
- since you can easily retrieve Components from a script with the system principal
- so having a low-privilege principal prevents privilege escalation through that mechanism
- myk: right, so we still want to remove Components from the scopes of sandboxes, but we also have to give them low-privilege principals
- irakli: regarding async IO bug
- if someone wants to use async IO already, here's a link to my github project which implements nodejs async APIs
- gabor: bug 680821
- would really need an answer about sandbox names
- if i'm right, then its patch will make about:memory gives you memory footprint based on module filenames
- but i thought we want memory footprint of addon rather than individual modules
- myk: where did that patch come from so we can determine the original intent?
- wes: that patch came from bug 673331
- mossop: sandboxName parameter was just added to platform, appears in about:memory
- mossop: if you give sandboxes the same name, does it group them together or separate them out?
- brian: we want something hierarchical with addon under which is modules
- mossop: ideal, not sure we'll get that
- mossop: unique name per module seems right
- mossop: but should use URI, not filename
- myk: gabor, is that ok with you?
- gabor: yes, i'm fine with that, it just means that i'll need to use a different name when merging compartments per addon