• milestones, checkpoints, regressions, stability and "demoability"
• proxy owners when someone is pto or at a conference
• Specs and other plans for 0.5.04
• A Bug Model for Chandler
• Debrief followup continued

Constant demoability

If our Chandler development practice includes the ideal that Chandler doesn't regress, doesn't that mean that Chandler should always be demoable? There are two problems with that:

• Regressions do occur even though we strive to meet the no-regression ideal
• New work gets added in a way that isn't immediately demoable -- not polished enough at the beginning.

Should checkpoints or milestones be demoable? We all seem to agree that we can't make checkpoints be demoable consistently. We should strive for milestones being demoable, however.

We do run smoke tests at each checkpoint to see whether completed features continue to work. When there's a problem in smoke test we add a critical regression bug with high priority though we don't usually re-create the checkpoint build. We don't feel that this ensures constant demoability, however, because even if Chandler passes a smoke test there may be new features, not yet covered by smoke test, which aren't polished enough to appear in a demo yet. Perhaps we're trying to meet too high a bar of "demoability", too polished and certain. What we're really doing is ensuring a certain level of stability -- Chandler should be stable.

Anything beyond this constant stability -- Can we quantify the amount of time spent preparing for a demo? Taking the D conf demo as an example:

• Aparna spent 1.5 days testing the demo script and another half day writing scripts.
• In the application team, Alec spent 1 day, John 1 day, Bryan 1 day, Jed 1 day, and Philippe at least a half-day management.
• Heikki spent 0.5 day and Bear probably spent 1 day
• Pieter?
• Morgen?
• Brian Moseley?

Note that this isn't entirely work that we wouldn't have had to do; some of it is work that we would have done later and simply push up in priority due to an upcoming demo.

To do a real, polished demo, as with a D Conference demo, we need

• Advance warning and discussion over whether we can use a milestone build
• A script, at least a rough outline two weeks before the demo
• QA to start running the script and entering bugs
• Developers need to shift gears if demo bugs appear in their area
• Branch for demo -- probably a few days before demo.

Back to the issue of constantly working application, one that generally doesn't regress. To ensure this we do this in routine practice:

• Ask developers to unit test and test their new stuff
• Run checkpoint builds, QA run acceptance tests, and enter any failures as critical regression bugs
• Fix critical regression bugs early but not re-build the checkpoint
• When we do a milestone, keep on working on that build until it passes all acceptance tests

Proxy owners for absentees

Katie asked for more advance planning from process owners when they're going to be on vacation. Make sure that the process is either going to be handled, and by whom, or isn't . E.g. Lisa's weekly status mails -- don't get done while she's gone (generally). When Heikki is gone Lisa will own all his processes (or find an owner). It would be best of somebody sends out mail and says "I'm gone for this period and these processes will be handled by so-and-so".

SPec status

Reviewed ZeroPointSixPlanning and updated....

Wiki changes?

Discussed what would go in Documentation area -- unclear what exists and what would go there. Lisa to follow up by collecting content/links and documenting.

Linux build

FC4 vs Ubuntu? Ubuntu is gaining ground no decision right now