Labs/Jetpack/Weekly Meeting/2011-07-26: Difference between revisions
< Labs | Jetpack | Weekly Meeting
Jump to navigation
Jump to search
(→Agenda) |
No edit summary |
||
Line 10: | Line 10: | ||
** [https://groups.google.com/forum/#!topic/mozilla-labs-jetpack/8lGmgQdnqno sandboxes vs jsm] | ** [https://groups.google.com/forum/#!topic/mozilla-labs-jetpack/8lGmgQdnqno sandboxes vs jsm] | ||
** [https://bugzilla.mozilla.org/show_bug.cgi?id=672443 too many compartments] | ** [https://bugzilla.mozilla.org/show_bug.cgi?id=672443 too many compartments] | ||
= Minutes = | |||
== 1.1 status == | |||
=== Will === | |||
* working on making the docs server redundant | |||
* got review from Brian yesterday | |||
* patch probably needs a couple more rounds of review | |||
* question of whether or not to implement Makefile-like behavior | |||
* also looked at doc Alex wrote about content script proxies | |||
* not yet ready, need to talk to Alex to talk about what's going on | |||
* want to document security model for SDK addons | |||
* what sort of access addons and content scripts have | |||
* worried about just pointing people at unsafeWindow | |||
* Irakli: i can be helpful in talking about content proxy | |||
* Will to talk to Irakli about it | |||
* talking to someone in UX team | |||
=== Gábor === | |||
* started work on a number of small issues | |||
** {{bug|646575}} memory leak bug, commented in bug; learned a lot about memory introspection | |||
** pretty sure there isn't an object leaking, more like memory fragmentation | |||
** really would like someone more expert reading my ideas and responding | |||
** Irakli: mrbkap and agal might be good candidates to respond | |||
** mossop to find someone to look at it and respond | |||
* {{bug|672443}}: too many compartments | |||
** are we sure all compartments are coming from sandboxes? | |||
** seen some compartments being created in XPCOM as workaround | |||
** so perhaps we aren't actually creating as many compartments due to sandboxes as we think | |||
* {{bug|658909}}: Incorrect |this| binding when using call() with XRayWrappers | |||
** got up to the point where the last guy got stuck | |||
** complex code, need time to become familiar with it | |||
** think i know where it's happening, not yet sure why it's implemented the way it is | |||
** quite messy, has some problematic areas, but super-important | |||
=== Matteo === | |||
* spent last week with Irakli | |||
* selections problem | |||
** there was some behavior where it wasn't clear if it's a bug or not | |||
** still some question, spec isn't clear | |||
** going to fix it in the SDK the way myk and matteo agreed | |||
** working on a patch to implement that behavior | |||
=== Irakli === | |||
* some of this we already discussed last week | |||
* simplified module loader | |||
** some discussion on mailing list; created pull request | |||
** got some feedback from Nickolay Ponomarev | |||
** he had recommended JSMs, but after a second look and benchmarking, he has second thoughts | |||
** regardless, i think it's good to have a simplified module loader | |||
** simplifications are priority per recent feature discussions | |||
** the prototype implements those simplifications, should be easy to port to sandboxes if we want to stick with those instead | |||
** irakli wants to know what to do next with prototype | |||
* bugs on list | |||
** they were in dietrich's review queue | |||
** got his reviews last week and landed changes | |||
* worked on modules bugs | |||
** making require statements explicit: had patch last week, needed some work, work done, patch landed | |||
** use strict: want to use strict in our modules; landed, broke on nightly, did more work to identify issues and fix them | |||
** freezing module exports for tamper-proofness: blocked by {{bug|674195}}, have new patch that works around issue | |||
** created separate bug for documentation side; in will's review queue | |||
* created pseudo-code for e10s model | |||
* wanted to implement prototype, but blocked by module loader | |||
=== Eddy === | |||
* finished measurements, talked to bsmedberg, posted in dev.platform | |||
* getting some feedback, but not 100% sure how to proceed | |||
* started working on several e10s bugs | |||
* ran into the same problems as Gábor: it's hard to start with stuff like that | |||
* so moved to some simpler bugs in SpiderMonkey | |||
* two hours ago i just posted my first patch | |||
* plan to move to several other bugs and slowly work to more e10s stuff to get progressively more familiar with what i need to know | |||
* dev.platform discussion: mostly suggestions for improving measurements | |||
* also suggestion that we can improve on content process footprint significantly | |||
* not clear if footprint is just data or includes code segment | |||
* will get info from e10s team on their plans | |||
=== Brian === | |||
* polishing off review queue, getting back to bugs | |||
* closed some 1.1 bugs as wontfix | |||
* some bugs are too hard and not important enough to fix | |||
** require detector should be comment-aware: do folks really care, or can we wontfix it | |||
** removing packaging from globals | |||
* highest priority work this week is to look over irakli's loader proposal and e10s stuff | |||
=== Myk === | |||
* review and email queues | |||
** making progress, but not caught up yet | |||
* release engineering work to get tests passing on test automation | |||
** folks have been fixing test failure bugs | |||
** getting to the point where remaining failures require access to buildslaves to diagnose | |||
** lukas ready to give access to buildslaves when i say the word | |||
* disabling compatibility check when running tests to avoid test automation bustage when Firefox version changes on Firefox/Gecko development branches | |||
** Wes: is this as easy as setting a checkCompatibility flag? | |||
** Myk: it might be! | |||
== Development Process == | |||
* no significant change from last week | |||
* plan to be finalized soon, but don't expect any changes | |||
* that means 1.1 merge from dev to stabilization branch happens next Tuesday | |||
* but that doesn't mean it's time to crash-land patches! | |||
* land only what's ready, the next release is right around the corner | |||
* that's the point of having a rapid release process; releases every six weeks | |||
* mossop, dveditz: how are we tracking features for 1.1? | |||
* myk: picture unclear, as we're transitioning from dev plan pages to feature pages | |||
* in the meantime, work (both features and bugs) is being tracked in bugs targeted at 1.1 | |||
* dveditz: are page-mods intended to protect users from malicious addons or addons from malicious web pages? | |||
* warner: the latter | |||
* dveditz: ok, good, as expected | |||
== Add-on Builder Workshops == | |||
* we're doing workshops in two locations: London and SF Bay Area | |||
* London workshop is happening September 29 6-10:30pm | |||
* three sessions: Interacting with Web Content, Adding to the Firefox UI, and Libraries and Modules | |||
* possible advanced topic session: using API Utils and other Advanced Platform Services | |||
* need leaders and assistants for sessions | |||
* everyone should think about leading or assisting a session | |||
* get back to Myk and mossop within the next day or two about it | |||
== Roundtable == | |||
* Irakli looking for feedback on: | |||
** Prototyping E10S API | |||
** Simple module loader | |||
** sandboxes vs jsm | |||
** too many compartments | |||
* E10S API is particularly important | |||
* Myk: everyone working on E10S should look at it and provide feedback to Irakli | |||
* Brian to look at it and provide feedback in the next couple days |
Revision as of 18:40, 26 July 2011
Agenda
- FlightDeck 0.9.7 status
- SDK 1.1 status
- Development Process
- Add-on Builder Workshops
- Roundtable
Minutes
1.1 status
Will
- working on making the docs server redundant
- got review from Brian yesterday
- patch probably needs a couple more rounds of review
- question of whether or not to implement Makefile-like behavior
- also looked at doc Alex wrote about content script proxies
- not yet ready, need to talk to Alex to talk about what's going on
- want to document security model for SDK addons
- what sort of access addons and content scripts have
- worried about just pointing people at unsafeWindow
- Irakli: i can be helpful in talking about content proxy
- Will to talk to Irakli about it
- talking to someone in UX team
Gábor
- started work on a number of small issues
- bug 646575 memory leak bug, commented in bug; learned a lot about memory introspection
- pretty sure there isn't an object leaking, more like memory fragmentation
- really would like someone more expert reading my ideas and responding
- Irakli: mrbkap and agal might be good candidates to respond
- mossop to find someone to look at it and respond
- bug 672443: too many compartments
- are we sure all compartments are coming from sandboxes?
- seen some compartments being created in XPCOM as workaround
- so perhaps we aren't actually creating as many compartments due to sandboxes as we think
- bug 658909: Incorrect |this| binding when using call() with XRayWrappers
- got up to the point where the last guy got stuck
- complex code, need time to become familiar with it
- think i know where it's happening, not yet sure why it's implemented the way it is
- quite messy, has some problematic areas, but super-important
Matteo
- spent last week with Irakli
- selections problem
- there was some behavior where it wasn't clear if it's a bug or not
- still some question, spec isn't clear
- going to fix it in the SDK the way myk and matteo agreed
- working on a patch to implement that behavior
Irakli
- some of this we already discussed last week
- simplified module loader
- some discussion on mailing list; created pull request
- got some feedback from Nickolay Ponomarev
- he had recommended JSMs, but after a second look and benchmarking, he has second thoughts
- regardless, i think it's good to have a simplified module loader
- simplifications are priority per recent feature discussions
- the prototype implements those simplifications, should be easy to port to sandboxes if we want to stick with those instead
- irakli wants to know what to do next with prototype
- bugs on list
- they were in dietrich's review queue
- got his reviews last week and landed changes
- worked on modules bugs
- making require statements explicit: had patch last week, needed some work, work done, patch landed
- use strict: want to use strict in our modules; landed, broke on nightly, did more work to identify issues and fix them
- freezing module exports for tamper-proofness: blocked by bug 674195, have new patch that works around issue
- created separate bug for documentation side; in will's review queue
- created pseudo-code for e10s model
- wanted to implement prototype, but blocked by module loader
Eddy
- finished measurements, talked to bsmedberg, posted in dev.platform
- getting some feedback, but not 100% sure how to proceed
- started working on several e10s bugs
- ran into the same problems as Gábor: it's hard to start with stuff like that
- so moved to some simpler bugs in SpiderMonkey
- two hours ago i just posted my first patch
- plan to move to several other bugs and slowly work to more e10s stuff to get progressively more familiar with what i need to know
- dev.platform discussion: mostly suggestions for improving measurements
- also suggestion that we can improve on content process footprint significantly
- not clear if footprint is just data or includes code segment
- will get info from e10s team on their plans
Brian
- polishing off review queue, getting back to bugs
- closed some 1.1 bugs as wontfix
- some bugs are too hard and not important enough to fix
- require detector should be comment-aware: do folks really care, or can we wontfix it
- removing packaging from globals
- highest priority work this week is to look over irakli's loader proposal and e10s stuff
Myk
- review and email queues
- making progress, but not caught up yet
- release engineering work to get tests passing on test automation
- folks have been fixing test failure bugs
- getting to the point where remaining failures require access to buildslaves to diagnose
- lukas ready to give access to buildslaves when i say the word
- disabling compatibility check when running tests to avoid test automation bustage when Firefox version changes on Firefox/Gecko development branches
- Wes: is this as easy as setting a checkCompatibility flag?
- Myk: it might be!
Development Process
- no significant change from last week
- plan to be finalized soon, but don't expect any changes
- that means 1.1 merge from dev to stabilization branch happens next Tuesday
- but that doesn't mean it's time to crash-land patches!
- land only what's ready, the next release is right around the corner
- that's the point of having a rapid release process; releases every six weeks
- mossop, dveditz: how are we tracking features for 1.1?
- myk: picture unclear, as we're transitioning from dev plan pages to feature pages
- in the meantime, work (both features and bugs) is being tracked in bugs targeted at 1.1
- dveditz: are page-mods intended to protect users from malicious addons or addons from malicious web pages?
- warner: the latter
- dveditz: ok, good, as expected
Add-on Builder Workshops
- we're doing workshops in two locations: London and SF Bay Area
- London workshop is happening September 29 6-10:30pm
- three sessions: Interacting with Web Content, Adding to the Firefox UI, and Libraries and Modules
- possible advanced topic session: using API Utils and other Advanced Platform Services
- need leaders and assistants for sessions
- everyone should think about leading or assisting a session
- get back to Myk and mossop within the next day or two about it
Roundtable
- Irakli looking for feedback on:
- Prototyping E10S API
- Simple module loader
- sandboxes vs jsm
- too many compartments
- E10S API is particularly important
- Myk: everyone working on E10S should look at it and provide feedback to Irakli
- Brian to look at it and provide feedback in the next couple days