Platform/2009-07-07: Difference between revisions

m
 
(26 intermediate revisions by 16 users not shown)
Line 1: Line 1:
<small>[[Platform/2009-06-23|&laquo; previous week]] | [[Platform|index]] | [[Platform/2009-07-07|next week &raquo;]]</small>
<small>[[Platform/2009-06-30|&laquo; previous week]] | [[Platform|index]] | [[Platform/2009-07-14|next week &raquo;]]</small>


=== Notices / Schedule ===
=== Notices / Schedule ===
* '''[[Releases/Firefox 3.0.12|Firefox 3.0.12]]'''
'''[[Releases/Firefox 3.0.12|Firefox 3.0.12]]'''
* built, being tested
* shipping to beta next Tuesday


'''[[Releases/Firefox 3.0.13|Firefox 3.0.13]]'''
* blocker list this week, [https://bugzilla.mozilla.org/buglist.cgi?keywords_type=nowords&keywords=fixed1.9.0.13+verified1.9.0.13&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=blocking1.9.0.13%2B&order=map_assigned_to.login_name,bugs.bug_id mostly complete]
* code freeze in ~1 month
* opening for landings on Wednesday


'''[[Releases/Firefox_3.5|Firefox 3.5]]'''
'''[[Releases/Firefox_3.5|Firefox 3.5]]'''
Line 15: Line 21:
** narrow scope, small changes
** narrow scope, small changes
** contrary to some reports on the Internet, this is the usual process for Firefox and software releases; the 3.5 release was strong, stable and solid, and feedback has been extremely positive. Near the end of the release we become extremely conservative about patches to accept; the 3.5.1 release is a quick update to fold in some patches that came up late in the 3.5 release cycle.
** contrary to some reports on the Internet, this is the usual process for Firefox and software releases; the 3.5 release was strong, stable and solid, and feedback has been extremely positive. Near the end of the release we become extremely conservative about patches to accept; the 3.5.1 release is a quick update to fold in some patches that came up late in the 3.5 release cycle.
'''Firefox 3.6a1'''
* code freeze 21-July?


=== Blocker Report ===
=== Blocker Report ===
Line 22: Line 31:


=== Browser / Front End ===
=== Browser / Front End ===
* posted the [Firefox/Goals/2009Q3 Q3 team goals for Firefox] on the wiki, as well as the evaluation of [Firefox/Goals/2009Q2 last quarter's goals]
* posted the [[Firefox/Goals/2009Q3|Q3 team goals for Firefox]] on the wiki, as well as the evaluation of [[Firefox/Goals/2009Q2|last quarter's goals]]
* Firefox.next
* Firefox.next
** moving on to [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=sw:tsnap TSnap] bugs which aim to make Firefox observably faster
** moving on to [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=sw:tsnap TSnap] bugs which aim to make Firefox observably faster
Line 28: Line 37:
** also returning to [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=polish- polish] bugs and [[Firefox/Sprints|exploratory sprints]]
** also returning to [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=polish- polish] bugs and [[Firefox/Sprints|exploratory sprints]]
** Reminder to review the [[Firefox/Namoroka|Firefox.Next plan]] and add your comments/feedback on the [[Talk:Firefox/Namoroka|discussion page]] or in the [http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/cba189f02aa448d8# dev-apps-firefox thread]
** Reminder to review the [[Firefox/Namoroka|Firefox.Next plan]] and add your comments/feedback on the [[Talk:Firefox/Namoroka|discussion page]] or in the [http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/cba189f02aa448d8# dev-apps-firefox thread]
* Polish update: Firefox is 59% shiny (-1% change)
** 43 remaining [http://tinyurl.com/8qnba2 easy polish bugs] (whiteboard [polish-easy])
** 39 remaining [http://tinyurl.com/9zq9xz hard polish bugs](whiteboard [polish-hard])
https://spreadsheets.google.com/pub?key=pMZGKUlD9NOPg4oJGs1CUMw&oid=1&output=image&foo=.png


=== GFX Update ===
=== GFX Update ===
* Finished collecting our Q3 goals. Full list available [[Platform/2009-Q3-Goals#GFX|on the wiki]]. Please let us know if we've missed anything. Highlights:
* {{bug|753}} work continues apace, with several people building on it.
** Hardware acceleration.
** If you are doing work that depends in any way on imgIContainer, gfxIImageFrame, nsIImage, you should base them on bug 753.
** Multiprocess work.
* Decode-on-draw work is happening in {{bug|435296}}.
** Cairo software performance.
* Jeff's working on an event profiler that has shown some bugs in imagelib; once those are resolved there will undoubtedly be others.
** Cairo capabilities.
* #4 topcrasher {{bug|470487}} fix should now be possible that nsWindow refactoring has landed. There have been very few, quite easy to fix regressions from that refactoring.
** Font system enhancements.
** Decode-on-draw for images.
** Windows integration work (mostly Win7).
* Not a lot to report, lots of ongoing work in the above areas. Highlights of that work:
** Pixman image scaling - better quality scaling. Trying to land soon.
** {{bug|753}} in progress, chasing a few last bugs in the patch before going through more intensive testing & review.
** Decode-on-draw in initial stages of development.
** nsWindow refactoring landed.


=== Layout Update ===
=== Layout Update ===


* Compositor phase 1 patches up for review, trying to figure out who gets the reviews (roc)
* Nothing major to report since last week
* SMIL/CSS up for review (dholbert)
* SVG/MathML in HTML5 parser rocks
* Frame poisoning ready to land (zwol), investigating per-type freelists
* HTML5 parser creates giant text nodes, should raise priority of work on performance of layout of very large text nodes
* Harfbuzz work in progress, should land prototype on trunk in a few weeks (jfkthame)
* Opentype feature spec posted to CSS WG (jdaggett)
* Lots of gruesome font format discussions
* Transitions spec issues (dbaron)
* Reworking Ogg decoding (doublec)
* Ogg indexing (cpearce)
* Ogg fuzzing (mgregan)
* jemalloc issues (karlt)


=== Content Update ===
=== Content Update ===


* HTML5 parser landed! (preffed off -- about:config pref is "html5.enable")
* HTML5 parser landed! (preffed off -- about:config pref is "html5.enable".)
* peterv's slimwrappers ready to land (modulo fixing an existing leak that was triggered by this work)
* peterv's slimwrappers landed, moving on to further optimizations that can be done now that the main work enabled.
* bent got the test plugin to draw when running out of process.
* Ben Newman is working with Henri Sivonen on figuring out what still needs to be done with the generated code in the HTML5 parser (cleanup of the generated code etc, so work on the generator itself).
* Lots of awesome plugin code simplification going on (Josh).
* Josh is almost (completely?) done with XPCOM plugin interface removal and interface consolidation in the plugin module.
* LiveConnect removal patch up for review.
* Starting to work out what the security model for JetPack's should look like.
* LiveConnect R.I.P.


=== Mac OS X Update ===
=== Mac OS X Update ===
* Steven Michaud fixed major OnStopFrame crasher, bug {{bug|499600}}.
* Markus Stange is very close to having a completed patch for fullscreen in 1.9.2, {{bug|420491}}.
* 64-bit Mac OS X port blocked on gfx {{bug|493280}}.
* Cocoa NPAPI event model coming along, part of it landed, maybe 70% complete at this point.


=== JS ===
=== JS ===
* landed https://bugzilla.mozilla.org/show_bug.cgi?id=200505. big perf win on some benchmarks.
=== Static Analysis ===


* looked some at Google's [http://code.google.com/p/sputniktests/ Sputnik] ES3 testsuite
* Dan Witte will be working on static analysis for code cleanup, performance, and correctness improvements
** none of our existing failures are too serious
* for instance, {{bug|502775}}, {{bug|172937}}, and more seriously JS GC safety - {{bug|421934}}
** some errors are codified in ES5
* suggestions for analysis passes we could use are welcome
** a large number of existing failures can be tracked to giving native functions (those built into ES5 itself) .prototype
** many also due to reading all input as ASCII when Sputnik expects UTF-8, see {{bug|495970}} and {{bug|501265}}, probably will switch to read input as UTF-8 for simplicity
** work on bugfixes probably not particularly high-priority, will keep an eye on things as UTF-8 and similar bugs are fixed to clear out the low-hanging fruit


=== Security ===
=== Security ===
Line 84: Line 87:
=== Electrolysis ===
=== Electrolysis ===


Work progressing: phase I not quite finished. The project repository is almost populated, and a bug has been filed to get buildbot/tinderbox builds.
Phase I completed. Repository is in place and builds on Windows/Linux.
 
cjones still work on minor protocol issues and bsmedberg hooking up automated ipdl generation.


cjones working on IPC protocol layer.
bent working on xpcshell extensions that will allow scripting the remote process for testing and prototyping.


Test plugin drawing from separate process on Windows.
bsmedberg doing local buildbots until RelEng can hook up a full project... reporting to [http://tinderbox.mozilla.org/Electrolysis/ tinderbox].


=== Tree Management ===
=== Tree Management ===
* tp4 enabled on mozilla-central last week
** tp4 == 100pages, c15mins to complete; tp3 == 400pages, c60mins to complete
** still to enable on other branches, nom'd 1.9.1.1 bug
** once tp4 rollout completed, want to power off fast talos machines, and EOL tp3
* new graph server (graphs.m.o), old is now called graphs-old.m.o
** new dashboard at [http://graphs.mozilla.org/dashboard/]
* working with IT to power up more machines in colo; needed for places, electrolysis, wait times.


=== Roundtable (both topics deferred to next week) ===
=== Roundtable ===
* Everyone should read [[Platform/2009-Q3-Goals|other teams' goals]].
* keeping trunk stable for the next few months (beltzner)
** landings that affect broad areas of the code should be discussed here and in dev-planning, first
** landings with many regressions should be backed out instead of waiting for follow-on fixes
** goal is to stabilize for 3.6 alphas/betas upon which Fennec will likely ship
* major update from 1.9.1-nightly to trunk-nightly? (beltzner)
* triaging blocking nominations earlier in the cycle? (dbaron)
* triaging blocking nominations earlier in the cycle? (dbaron)
** getting regressions fixed when people still remember the code that caused them
** getting regressions fixed when people still remember the code that caused them
Confirmed users
446

edits