canmove, Confirmed users
2,056
edits
Labs/Jetpack/Weekly Meeting/2011-08-02: Difference between revisions
Jump to navigation
Jump to search
Labs/Jetpack/Weekly Meeting/2011-08-02 (view source)
Revision as of 20:25, 2 August 2011
, 2 August 2011→Minutes
Dandonkulous (talk | contribs) (→Agenda) |
|||
| Line 16: | Line 16: | ||
= Minutes = | = Minutes = | ||
== FlightDeck | == afternoon presentation == | ||
* Dave Herman: I am on ECMAScript committee on modules | |||
* Reswana Karim is research intern working with us this summer | |||
* we work on ES modules, CommonJS modules, merging them | |||
* Ben Lerner is at Mozilla HQ today | |||
* does research on browser extension mechanisms | |||
* Ben giving talk this afternoon 1:30pm PT | |||
* will be streaming on Air Mozilla | |||
* talking about his work on browser extension mechanisms | |||
* would love to have people watch | |||
* will track questions on IRC | |||
* mossop: will it be recorded and available later? | |||
* dherman: we'll try to make that happen | |||
* ben: and slides are a web page, will make them available afterward | |||
== what works best in meetings == | |||
* dcm: last couple weeks we went around person by person rather than specific items | |||
* for 1.0 we looked at blocker bugs | |||
* what works better for you? | |||
* irakli: i liked list of bugs for the development cycle in question | |||
* myk: status can be obtained asynchronously, let's use the meeting for stuff that needs face time | |||
* mossop: i agree with myk | |||
* myk: i wouldn't even go through every bug/feature for a release, just the stuff that needs special attention (f.e. at risk) | |||
* dcm: i agree, let's just make sure we do bring up stuff when we feel it needs discussing | |||
== FlightDeck 0.9.7 == | |||
* link goes to last round of bugs and adjustments, i.e. stuff in the way before we tackle our goals in earnest | |||
* piotr has been doing groundwork for AMO integration | |||
* blocked by AMO switching to oauth 2; this week we should be back up and running with their new auth | |||
* sean working on augmenting search facets to give people more clarity about search results | |||
* freeze is this friday | |||
* XPI building used to occasionally take a really long time | |||
* after recent fix (removal of unnecessary queue), it no longer does | |||
* now it takes 1.5-3 seconds, 6 at most | |||
* not sure how fast it is outside the US, f.e. in Europe | |||
* can folks test and report findings? | |||
* irakli: i was doing that a lot lately from Paris office, it was pretty fast | |||
* daniel to post graph showing improvement | |||
== SDK 1.1 == | == SDK 1.1 == | ||
* myk: merges to stabilization branch today | |||
* merge can happen any time in timezone of merger | |||
* if you haven't landed a feature yet, it's probably too late | |||
* but if it's really ready, land it before merge | |||
* keep in mind we have six weeks of stabilization before release | |||
* but also keep in mind that 1.2 is right around the corner | |||
* releases every six weeks, so no need to land features before they are ready | |||
* brian: have we decided where to land stabilization fixes and what to do about version numbers? | |||
* myk: not yet, but i'm thinking we land wherever is more appropriate and cherry-pick/merge as needed | |||
* re: versions, if we're willing to have wonky versions on dev, we don't need to fix our hard-coded versioning | |||
* just make sure stabilization has the right version numbers | |||
* which dev acquires in merges from stabilization to dev | |||
* but we should still fix our hard-coded versioning | |||
* irakli: lloyd wrote blog post about hotfix branch, something to consider | |||
* myk: i'm open to process changes, not stuck on current process, it's just v1 | |||
* http://lloyd.io/applying-gitflow | |||
== SDK 1.1 stabilization releases == | == SDK 1.1 stabilization releases == | ||
* myk: after merge, time to start releasing stabilization releases | |||
* before, we stabilized to an alpha or beta | |||
* now, alphas and betas are part of stabilization | |||
* plan is to ship one every week | |||
* not sure we're ready to ship the first alpha after merge today | |||
* myk: but how about we try shipping the first alpha after merge today | |||
* send me info about things you landed, i'll add them to release announcement | |||
* someone: can we have stabilization builds on Builder? | |||
* dbuc: we can put them on staging server, not sure about production server | |||
* dcm: maybe we can provide protected access to unstable SDK builds | |||
* dbuc: perhaps allow users to use unstable SDK builds but force addons that use them to be private | |||
* dbuc to investigate and report back about options | |||
== development process == | == development process == | ||
* finalized | |||
== Add-on Builder workshops == | == Add-on Builder workshops == | ||
* Jeff will hook up with Dan Horner about this | |||
* mossop has talked to most of team about leading and assisting sessions | |||
* about half of the needed positions are identified | |||
* still need to find a leader for one of the sessions | |||
* all this is about London; Bay Area workshop is still TBD | |||
* initial goal is 100-150 attendees | |||
* three groups to learn to create addons hands-on | |||
* assistants in the audience to help folks out | |||
* the plan is subject to change | |||
== Products team work week == | |||
* dcm: team set goals for projects | |||
* promised an answer for SDK-based addons by the end of the year | |||
* must be landed in the codebase, doesn't have to be shipped yet | |||
* aggressive timeline, but doable | |||
* probably means landing e10s support as well | |||
* right now AMO has goal of 600 new addons per month for the rest of the year | |||
* promised to make 50% be SDK-based | |||
* we're already at 10% | |||
* more features, engagement work will help | |||
* we have less control over it, but still important | |||
* AMO has knocked it out of the park in terms of meeting their goals | |||
* we have to do the same | |||
== feature pages == | == feature pages == | ||
* myk: when will initial drafts be public? | |||
* dcm: they already are at https://wiki.mozilla.org/Features/Jetpack | |||
* but they haven't been publicized yet | |||
* dcm to start publicizing them by the end of the week | |||
== SDK 1.2 planning == | == SDK 1.2 planning == | ||
* dcm: so far we've built generalized feature pages | |||
* we need to start building more specific feature pages | |||
* time to start taking a look at larger feature goals, start identifying first steps | |||
* first steps for mobile, first steps for e10s | |||
* but those might not be targeted to 1.2 | |||
* myk: so it's more important to make progress on our larger goals than target features for 1.2? | |||
* dcm: correct | |||
* will: at the moment, we're mostly dependent on bugzilla to track features | |||
* will we carry on doing that until there's something else? | |||
* dcm: idea behind feature pages have prompted larger question about toolsets to make sure everyone knows what's going on | |||
* tough question, involves product management tools, project management tools, bugzilla, tracking all that | |||
* dria tasked with figuring it all out | |||
* dria probably going to create team to work on these tools | |||
* bugzilla is what we have right now; hopefully we'll have a better answer soon | |||
* will: perhaps one immediate solution is table of bugs for release | |||
* dcm: in some ways, feature pages are meta-bugs, collections of bugs | |||
* dcm: speaking of bugs, everyone met wes kocher (kwierso) and jeff griffiths last week | |||
* wes will start giving us updates on the status of the bug database | |||
* conclusions we can make from bugzilla about status of project | |||
* to the point of quantifying bugginess of areas of the SDK | |||
* wes has started working on tool for this | |||
* i hope we start integrating this kind of status into this meeting every week | |||
* i wrote bugmaster proposal for job that wes is doing, happy to share on request | |||
== roundtable == | == roundtable == | ||
* Irakli: created etherpad page to guide feedback on loader simplification | |||
* please provide feedback! | |||
* also created feature page | |||
* probably should be part of another feature page (simplifying SDK generally) | |||
* feedback on how to build feature pages is welcome! | |||
* dcm: looks great, i may add to it over time | |||
* gábor: maybe off-topic, but if you know of platform bugs, please assign them to me and eddy | |||
* anything related to Jetpack | |||
* irakli: ping alex about proxy-based workarounds for platform bugs | |||
* gábor: yes, i'm going to look at that next | |||
* brian: problem with flushing stdout after dump, especially on windows | |||
* brian to send link to gábor | |||
* myk: other one is bug about using too many compartments, it'll probably require platform work | |||
* gábor: yup, i'm cc:ed on that one and will provide thoughts | |||
* irakli: i created some for js engine as well, will cc: gábor and eddy | |||
* wes: would be good to go over futured bugs | |||
* dcm: agreed; point well taken; there's a lot of pain in that; scary, but true | |||
* we have 1.2 and 1.3 milestones available now in bugzilla | |||
* myk: we should get a sense of how many bugs we can fix per cycle | |||
* wes: plus we should retriage 1.1 bugs that don't make the merge | |||
* irakli: for feature pages that already exist, can we start scheduling bugs for them? | |||
* dcm: yes! | |||
* myk: should we ask before editing feature pages to add bugs? | |||
* dcm: nope, have at it! | |||
* irakli: eddy, do we have a decision on processes? | |||
* eddy: not yet, might still take a while | |||
* need a strategy for working with e10s team | |||
* posted my findings, got some feedback, afterwards stagnation | |||
* would like to move toward working on bugs more related to OOP stuff | |||
* myk: perhaps it's time to try implementing with content processes and see how far we get | |||