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

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