Hi,
During the FC status meeting, we also talked about how we should be
working during the 3 weeks of Performance Tweaking we're going to be
starting now. I'll be trying here under to sort out and summarize the
various points that we talked about:
Handling the Bugalanche
--------------------------------
Bugs will be likely being pouring down in Bugzilla now that all the
features landed and can be tested. We need however to seriously focus on
Performance or risk to miss the opportunity entirely. We agreed on the
following:
* Bug Council will meet twice a week (Tuesday 4pm and Thursday 4pm)
* Only bugs marked as blockers will need to be fixed immediately,
taking precedence over perf work
* We're not discouraging people to fix bugs of course...
Communicating
--------------------
Digging through perf issues usually reveal a host of problems and
potential area of work in various places. It is important during that
period to communicate heavily so that we all know at any time who is
working on what. We also need to be open to being interrupted by other
devs and help out drilling through problems. Here's a list of ideas that
we identified during the meeting:
* We encourage (as in "not mandatory but really interesting") review
of code changes for perf work. A fresh look at code is often bringing
interesting questions/perspective during perf rework.
* Think about pairing people to go through scenarios. Andi proposed
to pair with Jeffrey to go over the new event use case.
* Communicate heavily on the use cases on the chandler-dev mailing list
* Use [Perf] in mailing list as a Subject prefix so to make things
easier for all
* Provide a summary of [Perf] emails on a regular basis (Philippe)
* Use wiki
(http://wiki.osafoundation.org/Projects/PerformanceProject) to list
areas being worked on and by who
Work load, work items, where to start
------------------------------------------------
* Check the wiki
(http://wiki.osafoundation.org/Projects/PerformanceProject) to look at
the most important 0.7 use cases as well as all the collection of perf tests
* Things we know: if they are areas (in your code) you know need
rework, log it in Bugzilla (don't forget the "perf" keyword) and try
that first
* We need to add a list of architectural issues to the wiki and start
discussions on them on the list (e.g. "When to commit?", "Too many UI
refresh", etc...)
* Check the "Target = 0.7release" AND "Keyword = perf" bugs for
things already logged and bootstrapping ideas
* Get competent with profiling (see
http://wiki.osafoundation.org/Projects/BusyDevelopersGuideToChandlerPerformanceOptimization)
This email officially starts the "Performance Tweaking" period so do not
use to comment and start conversation on the subject.
Cheers,
- Philippe
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
