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

From MozillaWiki
Jump to: navigation, search

Agenda

  • Repack Post-Mortem wrap-up & proposal
  • Flightdeck updates
  • SDK updates
  • 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

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