Agenda

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

• SDK 1.1
• SDK 1.1 stabilization releases
• development process
• Add-on Builder workshops
• feature pages
• SDK 1.2 planning
• roundtable
  • simple loader feedback
  • simple loader feature page

Minutes

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
• http://lloyd.io/applying-gitflow

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

• myk: when will initial drafts be public?
• dcm: they already are at https://wiki.mozilla.org/Features/Jetpack
• but they haven't been publicized yet
• dcm to start publicizing them by the end of the week

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

roundtable

• 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