Hi,

We had our daily Bug Council for Desktop and we're still having 6 blocking bugs: - 8950 (bear): is actually waiting for RC to be declared (so not really blocking) - 4 bugs (10456, 10526, 10537, 10540): in need of fix with a good chance of getting fixed soon
- 10528 (vajda): our daily index error issue

This last one is in the "scary" category. Not so much because that one is scarier than previous similar index issues, but rather because:
- we keep stumbling on those daily
- they're all different (no one identified source of all those issues)
- they're potentially really damaging to user's data (though, so far, no one reported final data loss)
- they're *really* difficult to repro

With all the time (and resources) in our hands, we could just wait till we weed out all of those one by one and slip till we get them all. We can't however afford such a solution for several reasons: - Though lots of people are pitching on those bugs, some are not contributing much and are somewhat blocked or will be soon. We could put everyone on those problems but there's a point where throwing more people at a problem doesn't really help solve it faster... - Cosmo will be releasing its 0.7 by the end of the week and is on time to make the Aug 27th release. Would be great for them to go live on Hub so that they are not blocked. The question is: if Desktop 0.7 is not released, do we want users to hit this new server with old 0.6.1 Chandler instances (the last official release)? Not really...

So, what do we do? Here's a plan:
- Chandler Desktop declares ZBR and branches as soon as the 4 "non index" bugs here above are fixed (hopefully this week) - We cut an RC and move ahead with the QA process (help from everyone in going through the test plan will certainly be required) - We release a Desktop 0.7.0 so that users can start using the Cosmo 0.7 upgraded hub with a version that matches - We continue to test, fix, etc... the upcoming index issues (and others recall class bugs if any) and follow up with an update *very soon* after, without waiting for all the other 0.7.1 things to come in (i18n, script recording, interop).

Mitigation elements:
-> we need to put in release notes high up that we're aware of such issues
-> we need to document and promote the use of export/reload (aka dump/reload) in said release notes so that users have a safe path while we work out those remaining index issues

I'm sure there's comments on such a plan so I'd be glad to hear them.

- Philippe

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev

Reply via email to