canmove, Confirmed users, Bureaucrats and Sysops emeriti
1,093
edits
(Created page with "== Meeting Details == * Wednesday Jan. 05, 2010 - 9:00am Pacific, 12:00pm Eastern, 16:00 UTC * 650-903-0800 or 650-215-1282 x92 Conf# 275 * 1-800-707-2533 (pin 369) Conf# 275 (U...") |
No edit summary |
||
| Line 16: | Line 16: | ||
*** 20 blockers, 22 bugs that need to get going | *** 20 blockers, 22 bugs that need to get going | ||
* Firebug update | * Firebug update | ||
** Firebug 1.6.1 being released today | |||
** Firebug now goes through the regular add-on review process | |||
* Skywriter update | * Skywriter update | ||
** msucan has created an initial very simple dryice tool to build the code | |||
** bugs opened on the loose ends for 1.0 | |||
** jwalker suggests that accessibility needs to be on the list, and that perhaps we don't want to move directly to 1.0 | |||
* Post-Firefox 4 developer tools | * Post-Firefox 4 developer tools | ||
** Web Console blockers will likely be landed in 2 weeks | |||
** by the end of January, it's possible that our plate will be completely clear of Firefox 4 blockers | |||
** kdangoor to schedule meetings to start narrowing down a problem space for the coming devtools | |||
** jwalker mentions that we do not have an in-person meetup scheduled | |||
** a February meeting in Mountain View may make sense | |||
*** we should try to get jblandy there as well | |||
== Roundtable == | == Roundtable == | ||
* pcwalton has made a framerate add-on | |||
** https://github.com/pcwalton/firefox-framerate-monitor | |||
** Built with Jetpack | |||
** uses the chrome module to do XPCOM stuff | |||
** that XPCOM stuff is the kind of stuff we want to build into the SDK | |||
* rcampbell's workspace add-on is becoming more usable | |||
** http://antennasoft.net/addons/workspace.xpi | |||
** one issue he had was opening a chrome window was something that didn't seem to fit Jetpack well and he used a traditional add-on instead | |||
** we need to raise issues like that with the Jetpack team to figure out the best approach | |||
* Add-on SDK "static linking" | |||
** it's proposed that the Add-on SDK will be "statically linked" with add-ons. | |||
** this means that the add-ons will include the Add-on SDK modules that they use | |||
** the devtools SDK should piggyback on the same mechanisms used there | |||
** what does this mean for bundled devtools? | |||
*** will the bundled devtools include a copy of the Add-on SDK/devtools SDK frozen at a particular version? | |||