« previous week | index | next week »
Engineering Meeting Details
- Tuesday 2014-10-28 - 11:00 am Pacific Standard Time
- Dial-in: Audio-only conference# 98411
- People with Mozilla phones or softphones please dial x4000 Conf# 98411
- US/Toll-free: +1 800 707 2533, (pin 4000) Conf# 98411
- US/California/Mountain View: +1 650 903 0800, x4000 Conf# 98411
- US/California/San Francisco: +1 415 762 5700, x4000 Conf# 98411
- US/Oregon/Portland: +1 971 544 8000, x4000 Conf# 98411
- CA/British Columbia/Vancouver: +1 778 785 1540, x4000 Conf# 98411
- CA/Ontario/Toronto: +1 416 848 3114, x4000 Conf# 98411
- UK/London: +44 (0)207 855 3000, x4000 Conf# 98411
- FR/Paris: +33 1 84 88 37 37, x4000 Conf# 98411
- Gmail Chat (requires Flash and the Google Talk plugin): paste +1 650 903 0800 into the Gmail Chat box that doesn't look like it accepts phone numbers
- SkypeOut is free if you use the 800 number
- Engineering Vidyo Room / Air Mozilla / MTV Alien Nation / TOR Finch / SFO Warfield / PDX Hair of the Dog
- join irc.mozilla.org #planning for back channel
- 1 Need To Know
- 2 Quality Programs
- 3 Team Stand-ups
- 3.1 A*Team (jgriffin)
- 3.2 Accessibility (dbolter)
- 3.3 B2G Services (dougt)
- 3.4 Cloud Services (mmayo)
- 3.5 Desktop Platform (bsmedberg)
- 3.6 Developer Services (gps/lthomson)
- 3.7 Developer Tools (prouget)
- 3.8 DOM (jst/overholt)
- 3.9 Electrolysis (e10s) (blassey)
- 3.10 Firefox Desktop (gavin)
- 3.11 Firefox Mobile (snorp/blassey/mfinkle)
- 3.12 GFX (milan)
- 3.13 JS (naveed)
- 3.14 Layout (jet/dbaron)
- 3.15 Media (mreavy)
- 3.16 Necko (dougt/jduell)
- 3.17 Performance (vladan)
- 3.18 Seceng (dougt)
- 3.19 Shumway (tschneidereit)
- 3.20 WebAPI (overholt)
- 4 Roundtable
- 5 <Read only beyond this point>
Need To Know
(Release and system issues that may impact engineering this week.)
|Next Merge: June 5, 2023||Next Release: June 6, 2023|
|Central: 115||Aurora: 54||Beta: 114||Release: 113|
- 33.0.2 ships today - going out with updates enabled at 5% to collect data
- 34 beta4 desktop ships today
- 34 beta4 mobile ships tomorrow
- Next beta go to builds
- Desktop - Thu (beta5)
- Mobile - Mon (beta6)
Build Changes (gps)
(Build changes of which engineers should be aware.)
(Repo, test, and other information for engineers from the release engineering team.)
(System outages/upgrades and tree closures that impact engineering.)
- Tree Closing Window on Saturday, November 1. bug 1087431 is the tracker.
- An unusually long window -- approx 11-1/2 hours.
- Most of the work is network related, with interruptions in traffic from time to time.
- We'll leave trees "open", but developers should expect longer than normal build times and potential need to restart some jobs.
(An opportunity to hear about status with the various quality programs that do not have a formal team structure.)
- Past week's OrangeFactor: 7.77 (last week: 4.41).
- Android 4.0 talos was hidden across all trees last week. Some suites had failure rates as high as 37%. bug 1088019 tracks unhiding it.
- Overall Android 4.0 failure rates across all test suites is around 10%, not including jobs that get automatically retriggered by buildbot. bug 1059797 (landed on fx-team today after ~6wks of inactivity) will hopefully help, otherwise more hiding will be forthcoming.
- Numerous test disablings this week due to inactivity. More likely to come as I get time to go through the list.
- 30 intermittent failures marked as fixed in the last week - List - Thanks!.
- Thanks to William Chen for fixing bug 1033464, a longstanding Shadow DOM leak.
- Valentin Gosu fixed a significant memory regression involving resource timing that was detected by AWSY.
- Mike Hommey landed logalloc, a tool for recording and replaying heap allocations. It will allow easier testing of different heap allocators, such as jemalloc3.
- A lot of work still flowing into 33 release, atm mainly bug 1089413 (GFX, should be fixed in 33.0.2) and bug 1087674 (shutdown issues with OpenH264 updates being MITM-ed by Avast SSL scanning).
- Nightly and Aurora have some recent GFX issues to sort out.
- Nightly had a crash spike caused by the landing of bug 865314 (SSL/SPDY-related), fixed by backout in today's Nightly.
(In <2 mins, what did your team accomplish last week, on what is your team working on this week, and on what, if anything, is your team blocked? No questions during the stand-ups. All questions should be asked during the roundtable.)
B2G Services (dougt)
Cloud Services (mmayo)
Desktop Platform (bsmedberg)
- Telemetry is now submitting with a user ID, so we can measure things by user and not just by session.
- Step towards unifying FHR and Telemetry.
Developer Services (gps/lthomson)
Developer Tools (prouget)
- still focused on getting Service Workers usable on Maple
- fixing IndexedDB quota prompt situation with plan to uplift to Aurora
- please file any fallout from WebSocket in Workers bug 504553
Electrolysis (e10s) (blassey)
- Please help dogfood e10s in Nightly!
- To opt-in, open "Preferences" and check the "Enable E10S (multi-process)" checkbox.
- Known issues: https://wiki.mozilla.org/Electrolysis#What_to_Expect
- Enabling more e10s tests
- Watch for add-on breakage even with e10s disabled from bug 1030420 ("Enable dom.compartment_per_addon by default on Nightly"). This change is intended to help find e10s add-on bugs, even when e10s is disabled.
- Big changes to e10s printing (bug 927188) and plugins (bug 641685, bug 669200, bug 1044182) coming soon
- e10s maybe be enabled by default for Nightly testing within the next couple weeks, so please your test features and favorite add-ons now!
- Add-ons that specifically marked as e10s-compatible in their manifests will be disabled (bug 1088309) on e10s first run, but brave testers can reenable them.
Firefox Desktop (gavin)
Firefox Mobile (snorp/blassey/mfinkle)
Done since last week that might impact others
- worked on Reader mode/reading list
Doing this week that might impact others
- continuing work on reader mode/reading list
Working on that is dependent on others
- minifying JS is waiting on platform team dependency
- Desktop requirements, new B2G timeline and requirements - GFX has a meeting with all interested parties tomorrow to sort out the priorities of the new requests.
Mozilla SpiderMonkey in the news:
- SpiderMonkey is faster than V8 on Octane
- Roc's blog about SpiderMonkey on Octane
- Compiler (JIT)
- bug 1087232: Don't atomize eval strings for the eval cache
- bug 1087963: Fixed Array.prototype.slice to not be horribly slow on sparse arrays, issue reported by the Google Inbox people.
- Garbage Collection
- bug 650161 : Worked on compacting GC - Try to get CGC tests enabled on tbpl
- Front End and Other
- Shared object heap POC: working (locks, conditions, queues, arrays, structures); nice speedup on mbrot, raytrace though challenges remain
- bug 1088709: Implement SIMD loads/stores in the interpreter.
- What will your team do this week that might impact others?
- Investigating JSBench and BrowserMark 2.1 performance. We may need some help from other teams (DOM Network) to help figure out performance bottlenecks. Let me know who the right person(s) would be.
- W3C TPAC (CSS & SVG working groups) meeting face-to-face this week. Spec changes coming up!
- Continuing to dog down WebRTC issues in 2.1
- Improved getUserMedia framerate (regression due to bug 848954 (MediaStreamGraph rework)
- Hello (loop) is now fully un-throttled in Beta; everyone should see it in their customization panel
- Only small updates to Beta since last week for Hello, stable
- working to resolve Mac audio regressions from bug 848954 when switching audio outputs
- Alas, we had to back out enforcing HTTP framing (i.e. requiring content-length header to match actual length). Broke too many websites. This means the download manager will once again not warn about incomplete downloads. We have some plans for a more targeted set of fixes. (bug 1088850)
(Comments and questions that arise during the course of the meeting or otherwise do not have a section.)
- Portland All-Hands
- (Milan) Would like to have a session in Portland on alternatives to crash reports to get us back "bad failures". For example, we detect a bad driver, which leads to a the sub-optimal experience for the user. We fall back to non-accelerated setup, and warn the user about it, also letting them send us the information similar to what crash report would send. We'd need a lot of different teams represented - who should come, who should run with this?
- (lmandel) I'll take this as I'll be putting a broader session together that should include this topic.
- Portland All-Hands free time blocks wiki to advertise BoF sessions.
<Read only beyond this point>
Friends of the Tree
Mailing List Threads
(Threads that are likely to be of interest to engineering from various mailing lists.)
(Links to blog posts, books, videos, etc. that you think will be of interest to others.)
irc #planning Log From This Meeting
11:00 cpeterson: Link to meeting notes wiki: https://wiki.mozilla.org/Platform/2014-10-28 11:05 kbrosnan: airmo user just showed up 11:07 lmandel: cpeterson: I turned on recording for the meeting. We can upload to airmo afterwards. 11:08 cpeterson: lmandel: thanks 11:10 lmandel: bsmedberg: Probably worth reviewing the Telemetry FAQ to ensure that the userid doesn't require changes to any of the answers: https://wiki.mozilla.org/Telemetry/faq 11:11 lmandel: bsmedberg: Changes needed here too? https://www.mozilla.org/en-US/privacy/firefox/ 11:12 bsmedberg: lmandel: that should be all done, we reviewed that 3-4 months ago. 11:12 lmandel: bsmedberg: k. great 11:15 overholt: blassey, mrbkap, is it worth filing bugs about performance issues? 11:15 bsmedberg: overholt: not with plugins until tomorrow. Otherwise yes. 11:15 blassey: overholt: always worth filing 11:16 blassey: perf is getting prioritized after a whole bunch of other functional work for now 11:16 overholt: k. I'll try to formulate a useful report. 11:16 blassey: yes, two big things are the performance characteristics of plugins are about to change rather drasitcly 11:16 blassey: the other is certain addons are killing us 11:17 blassey: Adblock Plus being the number 1 offender 11:22 laura: milan_: count me in. the support API stuff is strongly related 11:26 jesup: milan_: The webrtc folk may be interested in such a discussion on reports 11:33 milan: laura, jesup: great, lmandel and I just chatted a bit, and it sounds there were already some conversations and something will be set up for Portland. This is one of those "needs to be heavily coordinated" things :) 11:34 lmandel: Indeed. I'll get some time on the Portland calendar for this. 11:35 jesup: We have bugs open on "dump useful data (if the user wants) sanatized after a call with a problem to a server" 11:37 laura: excellent, thanks! 11:37 laura: jesup: yeah I think I remember reading that - not a new bug, right? 11:38 jesup: laura: definitely not new 11:39 jesup: We wanted to have a button on about:webrtc to produce a report and dump it to a crashreporter-type setup