Personal tools

Labs/Jetpack/Weekly Meeting/2011-08-30

From MozillaWiki

Jump to: navigation, search

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

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
  • 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
  • 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