[Chandler-dev] Chandler Desktop End Game

[Philippe Bossut]

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