Reviewing 0.3 vs. 0.2.8 release plans

Can we fix the Derby blob size problem in a 0.2.x release?

• It's not easy -- can't be done in place
• Would require a data migration.

What does the 0.3 data upgrade/migration consist of?

• Run once
• Changing columns and stuff
• BCM will take the production databases (cosmo-demo and foxcloud) and use those to test the migration

What other changes in 0.3?

• Most destabilizing is the data structure changes -- nodes in different places
• These data structure changes were required to do REPORTs but of course such changes also affect the workings of the methods that FoxMarks^? uses.
• A new data structure, and how it's used, is could have different performance implications that we don't know about

Jared's take

• More excited about upgrading cosmo-demo than foxcloud
  • fewer production users on cosmo-demo,
  • lower expectations and promises on cosmo-demo

More info on Foxcloud

• A hardware upgrade was planned for FoxCloud^? this week but it's been deferred until upcoming software upgrade
• Can't announce FoxCloud^? publicly until we have a way of growing to some more users.
• Possible to grow slowly, however -- cut off creation of new accounts before hitting the Derby blob size limit.
• If we fix only the Jackrabbit performance problem in 0.2.8, then Todd and Jared are willing to use that for now, and then upgrade to 0.3 in order to get both the Derby blob size fix and other possible future fixes.
  • Note that 0.2.8 doesn't require a data upgrade if it only has the Jackrabbit perf fix, but fixing the derby blob size would require a data upgrade.

How we make sure cosmo is ready

• Extend functional tests -- particularly protocol tests, Litmus and Silmut
• More unit tests, unit tests need to be a priority (BCM and BKirsch)
• Mikael put together a Cosmo 0.3 test plan
• Todd's hammer tests
• Suggestion to focus on exactly what Chandler, Scooby and FoxMarks^? use in the protocol.
  • FoxMarks^? is already mostly covered with the hammer tests, and somewhat more in Silmut
• Wrapping this stuff together into a "functional test steps" is the first thing, then Bear can get that onto Tinderbox.

Should we fix our schema in order to resolve the 35000 user limit due to Derby blob size?

• The right fix long term would be something that actually saved us from encountering this problem multiple times.
• Possible wild-ass estimate for that work would be about a week
• Obviously this would also require an upgrade so doing that along with the rest of 0.3 data upgrade
• John Townsend suggested a schema review as we finish 0.3, particularly with these recent changes
• BCM will put two mails to the public list describing this proposal, and another thing he's thinking of fixing.

Decision to release 0.2.8

• First step is to make a checklist of what tests we need to run against 0.2.8 snapshot build
• Then code-freeze and hand-off as with other 0.2.x releases already done

Scooby release thoughts

• Waiting for Cosmo 0.3 release, in order to release Scooby, would mean waiting several weeks now with recent new info, possibly even over a month
• Having Cosmo 0.3 would require another run of Scooby tests, but we'd do another round of Scooby tests anyway, because we'd do another release of the Bundle then.
• Sense of closure important to people too
• No change of plan then, from releasing Scooby 0.1 with a snapshot of Cosmo

Test idea from Todd

• Get a special build of Cosmo that works around the Derby blob size limit in the cheapest way, so that FoxCloud^? testing can try to see what the next problem beyond that would be
• Possible, yes