Labs/Jetpack/Weekly Meeting/2011-10-4
From MozillaWiki
< Labs | Jetpack | Weekly Meeting
Contents
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)