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