Labs/Jetpack/Weekly Meeting/2011-10-4

Agenda

• Repack Post-Mortem wrap-up & proposal
• Flightdeck updates
• SDK updates
  • 1.2-targeted bugs
  • Myk: final call for feedback on three week offset proposal
• London Workshop report!
• Revisit Will's call for better release-notes process?
• Roundtable
  • Myk: final call for feedback on minVersion/maxVersion proposal
  • gozala: For some of our users review takes painfully long time, can we help ? [1]
    • KWierso: And apparently the repack removed the addons from the review queue so they had to start at the bottom?
  • dcm: Alex got a pagemod add-on working on mobile! On Github
  • dcm: Alex also started work on l10n stuff - bug & Feature page
  • gozala: Proper platform bug fixes instead of workarounds
  • jeff: websockets usage in SDK add-ons

Attendees

• myk
• mossop
• dcm
• kwierso
• canuckistani
• dbuc
• arron
• warner
• gozala
• ochameau
• zer0
• gabor
• will

Minutes

Repack Post-Mortem

• -> dcm to post proposal to addons blog and forum about repacks in the future
• first part is short term to only repack addons hosted on builder
• because we have sources for addons on builder
• it's hard to repack XPIs without access to sources

• long term ideas of creating source package that can be used by repacker
• and landing stuff into firefox
• proposal and announcement on forum later today
• you can see proposal in advance via etherpad

• dbuc: what about case of someone using the builder and then switches to SDK?
• dcm: as previously discussed, we should have flag that identifies addon as coming from builder
• dbuc: but should we send them an email each time we try to do a repack, saying we couldn't repack?
• dcm: good question, something for me to talk to fligtar about
• myk: doesn't matter whether or not it came from builder originally, question is whether it comes from builder now or not
• warner: yes, it's about whether or not we have source for it
• -> dcm to follow up with fligtar about it

FlightDeck Updates

• "push to AMO" feature pushed to production
• there was a problem because of some IT issue
• IT will correct the issue

• team is defining Q4 goals
• was going to land code completion, but have decided against it
• will now focus on making repack process better

• myk: still Q1 2012 for builder 1.0?
• dbuc: yes, early Q1, but should have technical stuff wrapped up this quarter
• early Q1 will be about developing a marketing plan, etc.

• warner: code completion changing in ACE?
• dbuc: they're going to gut package system, and code completion tried to package system, so it sounds like it'll change

• gozala: was at jsconf, talked to cloud nine folks, sounds like they plan to ship code completion very soon
• apparently already on their branch
• dbuc: sure; but there are other reasons to delay, like repacks, finishing 1.0

SDK Updates

• two extant bugs targeted to 1.2

• first bug about hotkeys regression
• gozala: could be fixed by fix for another bug, need feedback from myk on that
• myk: that looks like a new feature; this is a regression in 1.1; is there a short-term fix for the bug that doesn't require landing a new feature?
• myk: or perhaps other mitigating steps, like notifying authors of broken addons and adding a release note
• gozala: i think fix is simple, might be low-risk enough to get into 1.2
• myk: per request for feedback, allowing only non-printing characters seems reasonable
• -> dbuc to find out which addons were affected
• -> gozala to submit patch tomorrow

• ochameau: second bug is simple, has patch
• myk: patch has review, can you land it today? afterward i will cherry-pick to stabilization branch
• -> alex to land today
• -> myk to cherry pick to stabilization branch for 1.2

• myk: last call for feedback on three week offset proposal
• (general assent)
• alex: i would like to see a graphic to understand when releases are happening
• myk: i put a graphic into the |development process page
• i will update it with new dates and a simpler color scheme after finalizing the proposal

Bug Update

• wes: two bugs need followups from warner, bug 685378 and bug 663480

• warner: (something i didn't catch about first bug)
• warner: need to think about second bug
• -> warner to think about second bug

London Workshop Report

• jeff: it was a mixed success
• a bunch of people showed up
• well-received
• got good feedback
• not as many people as we wanted
• hacker newsgroup with free beer had just recently scheduled event for that night
• hundreds of people were there instead
• our event lacked beer
• we got about 40 people, including some who were addon developers and had used jetpack
• warner: i think about 50 rsvp, ended the event with 25, some attenuation over course of evening
• jeff: i think more like 65 rsvp plus 5 from college

• jeff: original format was three tracks, but we ended up doing it in one room
• venue issues, like not enough power strips
• material was generally good and well-received
• i have meeting with dan to collate media: video, pictures
• plan to do a blog post today
• have some ideas on how to improve it in the future
• there are a lot of social meetups with geeks
• competing with them is hard
• and it happened to be great weather
• we were supposed to have drinks, but there was a misunderstanding with college
• in the end we couldn't bring in outside catering and drinks
• next time we could do it in london office of sufficient size
• rethinking sf event, thinking of making it smaller, with just a couple of presenters, and hosted in sf office
• i'll draft up proposal of what sf event should look like

• one of the lessons was event was heavy in terms of people needing to travel
• in the future we should plan to make them more lightweight
• warner: we didn't do labs with people going through exercises, we should experiment with that
• jeff: yes, have ideas about doing sessions in morning and hack day in afternoon
• warner: we could experiment with employees who don't know much about addons

• matteo: i talked after jsfconf with dietrich...
• more than one workshop was a coneference
• because we lacked labs, it was noninteractive
• not clear the level of the workshop
• some people are new to addons or have just used them
• others are web developers and don't know anything about them
• perhaps have two different tracks; one for people who are new and a more advanced one
• warner: jeff, i'll get you my slides

• myk: any feedback on APIs or features?
• matteo: one guy who created addon for thunderbird asked if we are going to support other XUL apps
• jeff: folks asked when we're going to work on missing pieces, like prefs or places apis, but they aren't scheduled

• dbuc: did builder work?
• jeff: any problems we had were related to speed of network
• had some wifi issues, routed around them by using phone for internet
• warner: wifi was out for middle part; only four attendees had ac power

• jeff: we have minimum system requirements, the venue didn't meet them
• the devengage team is getting a developer events manager
• that person should be putting together boilerplate stuff with technical requirements, we can take them to venue and make sure they're met

Better Release Notes Process

• dcm: two weeks ago will asked for a process for letting him know about new features in release
• warner: recently i've been setting the target milestone of bugs i close
• myK: there's also the relnote keyword you can set on bugs that would benefit from a release note
• mossop: yes, if you set target milestone and then relnote keyword it's a simple bugzilla query
• dcm: think about it more, send out a message
• kwierso: make sure to identify relnote with cherry picked changes

• will: i don't want to make it hard, can troll through github history
• i'm also interested in knowing about the future instead of just the past
• want to know what's in 1.3, 1.4 before they happen
• partly out of interest, partly to prepare for documenting changes
• assume others want to know as well
• we used to have a wiki page of stuff we expect to show up for a release

• dcm: it's harder with train model
• will: that's ok, it's still good to know intention
• jeff: it would be useful for me, too
• dcm: one other option is what eddy has done with e10s documentation via etherpad
• i asked him to link to etherpad in feature page
• as feature page is canonical repository
• that's always an option

• myk: can happen, just requires effort from somebody
• dcm: don't think it's worth jumping off the train
• dcm: if everyone is keeping a good status update

• irakli: one thing that is helpful is to write good description of what pull request does
• you could get data fram pull request descriptions
• warner: same thing applies to merge commits
• myk: but pull requests and merge commits are about stuff in the past
• irakli: actually pull requests are the future, for those not yet closed

• myk: also there's smedberg's status tool for engineers on mossop's team
• dcm: pull requests and smedberg's tool might be the solution here, let's keep thinking

Roundtable

• myk: final call for feedback on minVersion/maxVersion proposal
• (none)

• irakli: user on forum is frustrated with review process and versioning
• not sure what to do, but i think we should do something about it
• review took longer than the SDK took to release a new version
• jeff: got comments on that at jsconf as well
• folks had an update in review queue, then we repacked their old version
• and no one had looked at their new version, which used 1.1
• that's between us and AMO
• dcm: hmm, not sure, something to talk to fligtar, jorge
• -> dcm to talk to fligtar

• irakli: also it's important to respond to the user
• -> jeff to get back to that user

• irakli: another item is platform bug fixes and feature additions
• while doing work for e10s and cleaning up module loader code i found a couple issues we're working around
• one is that we don't write to standard output because python can't handle it
• so we write to a file instead
• alex has a patch for it
• another is that there is no way to exit process by passing exit code
• so we work around that as well by writing to file
• since we have platform devs, is that something we can delegate to them and fix on platform side?
• mossop: yes, if we have things that need fixing in the platform, we have engs on the team to do that
• mossop: either speak to them directly or pass the bugs to me
• irakli: i can create bugs and cc: our platform devs
• -> irakli to do so

• dcm: alex got a pagemod addon working on mobile; it's on github, check it out!
• alex also started work on l10n stuff, there's a branch on which you can follow the work
• alex: we should start talking with gandalf and transifex team about maintaining online tool
• the more i think about it, i think we might not support online tool in first step
• so we should allow translation manually
• the first step will be to just allow translation in addon
• then improve it by connecting it to addon tool which will be ready later on
• because i just realized this tool is not maintained by anyone
• perhaps transifex team, which has contract with mozilla
• but will take some time to be ready
• dcm: sounds good to me, will talk to gandalf more about the online tool

• jeff: over the weekend i got email from 1password asking for advice on implementing websockets in addon
• seems like the only way to do it is in a page worker
• mozwebsocket as implemented requires dom to run, can't just require("chrome") and access it
• is that something we should address on platform
• irakli: that's one of the things i meant about limitations of using certain apis without creating a hidden window
• i think those things would be better fixed on the platform side
• (lots of discussion about medium term plan to load main addon code in a real web page environment)
• (some discussion of short term ways to address issue)