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

From MozillaWiki
Jump to: navigation, search


  • FlightDeck Update
    • Speeding up the xpi build times for the Add-on Builder (y axis in milliseconds)



afternoon presentation

  • Dave Herman: I am on ECMAScript committee on modules
  • Reswana Karim is research intern working with us this summer
  • we work on ES modules, CommonJS modules, merging them
  • Ben Lerner is at Mozilla HQ today
  • does research on browser extension mechanisms
  • Ben giving talk this afternoon 1:30pm PT
  • will be streaming on Air Mozilla
  • talking about his work on browser extension mechanisms
  • would love to have people watch
  • will track questions on IRC
  • mossop: will it be recorded and available later?
  • dherman: we'll try to make that happen
  • ben: and slides are a web page, will make them available afterward

what works best in meetings

  • dcm: last couple weeks we went around person by person rather than specific items
  • for 1.0 we looked at blocker bugs
  • what works better for you?
  • irakli: i liked list of bugs for the development cycle in question
  • myk: status can be obtained asynchronously, let's use the meeting for stuff that needs face time
  • mossop: i agree with myk
  • myk: i wouldn't even go through every bug/feature for a release, just the stuff that needs special attention (f.e. at risk)
  • dcm: i agree, let's just make sure we do bring up stuff when we feel it needs discussing

FlightDeck 0.9.7

  • link goes to last round of bugs and adjustments, i.e. stuff in the way before we tackle our goals in earnest
  • piotr has been doing groundwork for AMO integration
  • blocked by AMO switching to oauth 2; this week we should be back up and running with their new auth
  • sean working on augmenting search facets to give people more clarity about search results
  • freeze is this friday
  • XPI building used to occasionally take a really long time
  • after recent fix (removal of unnecessary queue), it no longer does
  • now it takes 1.5-3 seconds, 6 at most
  • not sure how fast it is outside the US, f.e. in Europe
  • can folks test and report findings?
  • irakli: i was doing that a lot lately from Paris office, it was pretty fast
  • daniel to post graph showing improvement

SDK 1.1

  • myk: merges to stabilization branch today
  • merge can happen any time in timezone of merger
  • if you haven't landed a feature yet, it's probably too late
  • but if it's really ready, land it before merge
  • keep in mind we have six weeks of stabilization before release
  • but also keep in mind that 1.2 is right around the corner
  • releases every six weeks, so no need to land features before they are ready
  • brian: have we decided where to land stabilization fixes and what to do about version numbers?
  • myk: not yet, but i'm thinking we land wherever is more appropriate and cherry-pick/merge as needed
  • re: versions, if we're willing to have wonky versions on dev, we don't need to fix our hard-coded versioning
  • just make sure stabilization has the right version numbers
  • which dev acquires in merges from stabilization to dev
  • but we should still fix our hard-coded versioning
  • irakli: lloyd wrote blog post about hotfix branch, something to consider
  • myk: i'm open to process changes, not stuck on current process, it's just v1

SDK 1.1 stabilization releases

  • myk: after merge, time to start releasing stabilization releases
  • before, we stabilized to an alpha or beta
  • now, alphas and betas are part of stabilization
  • plan is to ship one every week
  • not sure we're ready to ship the first alpha after merge today
  • myk: but how about we try shipping the first alpha after merge today
  • send me info about things you landed, i'll add them to release announcement
  • someone: can we have stabilization builds on Builder?
  • dbuc: we can put them on staging server, not sure about production server
  • dcm: maybe we can provide protected access to unstable SDK builds
  • dbuc: perhaps allow users to use unstable SDK builds but force addons that use them to be private
  • dbuc to investigate and report back about options

development process

  • finalized

Add-on Builder workshops

  • Jeff will hook up with Dan Horner about this
  • mossop has talked to most of team about leading and assisting sessions
  • about half of the needed positions are identified
  • still need to find a leader for one of the sessions
  • all this is about London; Bay Area workshop is still TBD
  • initial goal is 100-150 attendees
  • three groups to learn to create addons hands-on
  • assistants in the audience to help folks out
  • the plan is subject to change

Products team work week

  • dcm: team set goals for projects
  • promised an answer for SDK-based addons by the end of the year
  • must be landed in the codebase, doesn't have to be shipped yet
  • aggressive timeline, but doable
  • probably means landing e10s support as well
  • right now AMO has goal of 600 new addons per month for the rest of the year
  • promised to make 50% be SDK-based
  • we're already at 10%
  • more features, engagement work will help
  • we have less control over it, but still important
  • AMO has knocked it out of the park in terms of meeting their goals
  • we have to do the same

feature pages

SDK 1.2 planning

  • dcm: so far we've built generalized feature pages
  • we need to start building more specific feature pages
  • time to start taking a look at larger feature goals, start identifying first steps
  • first steps for mobile, first steps for e10s
  • but those might not be targeted to 1.2
  • myk: so it's more important to make progress on our larger goals than target features for 1.2?
  • dcm: correct
  • will: at the moment, we're mostly dependent on bugzilla to track features
  • will we carry on doing that until there's something else?
  • dcm: idea behind feature pages have prompted larger question about toolsets to make sure everyone knows what's going on
  • tough question, involves product management tools, project management tools, bugzilla, tracking all that
  • dria tasked with figuring it all out
  • dria probably going to create team to work on these tools
  • bugzilla is what we have right now; hopefully we'll have a better answer soon
  • will: perhaps one immediate solution is table of bugs for release
  • dcm: in some ways, feature pages are meta-bugs, collections of bugs
  • dcm: speaking of bugs, everyone met wes kocher (kwierso) and jeff griffiths last week
  • wes will start giving us updates on the status of the bug database
  • conclusions we can make from bugzilla about status of project
  • to the point of quantifying bugginess of areas of the SDK
  • wes has started working on tool for this
  • i hope we start integrating this kind of status into this meeting every week
  • i wrote bugmaster proposal for job that wes is doing, happy to share on request


  • Irakli: created etherpad page to guide feedback on loader simplification
  • please provide feedback!
  • also created feature page
  • probably should be part of another feature page (simplifying SDK generally)
  • feedback on how to build feature pages is welcome!
  • dcm: looks great, i may add to it over time
  • gábor: maybe off-topic, but if you know of platform bugs, please assign them to me and eddy
  • anything related to Jetpack
  • irakli: ping alex about proxy-based workarounds for platform bugs
  • gábor: yes, i'm going to look at that next
  • brian: problem with flushing stdout after dump, especially on windows
  • brian to send link to gábor
  • myk: other one is bug about using too many compartments, it'll probably require platform work
  • gábor: yup, i'm cc:ed on that one and will provide thoughts
  • irakli: i created some for js engine as well, will cc: gábor and eddy
  • wes: would be good to go over futured bugs
  • dcm: agreed; point well taken; there's a lot of pain in that; scary, but true
  • we have 1.2 and 1.3 milestones available now in bugzilla
  • myk: we should get a sense of how many bugs we can fix per cycle
  • wes: plus we should retriage 1.1 bugs that don't make the merge
  • irakli: for feature pages that already exist, can we start scheduling bugs for them?
  • dcm: yes!
  • myk: should we ask before editing feature pages to add bugs?
  • dcm: nope, have at it!
  • irakli: eddy, do we have a decision on processes?
  • eddy: not yet, might still take a while
  • need a strategy for working with e10s team
  • posted my findings, got some feedback, afterwards stagnation
  • would like to move toward working on bugs more related to OOP stuff
  • myk: perhaps it's time to try implementing with content processes and see how far we get