Hi Eric,
eric.bachard wrote:
Hi,
Thank's for your complete answer. In fact it was my fault : I didn't know, but I can add QA member "by hand".
My mistake was to believe I only had to choose in the list (what I'd prefer).
But if that list contained all registered OOo members, it would ne unusable ...
Now Laurent has to verify if he can modify QA status. If so, no more problem :-)
I think technically that will be possible. The problem - as mentioned in this thread - is that we don't have complete documentation (and possibly tooling) how to do CWS QA yet.
We also have a gatekeeper, who watches for process violations and may stop a CWS even after QA approval, if the QA was not done according to the rules. But it is hard to do everything correctly when the rules aren't fully documented yet :-(
Things to do include (but may not be limited to):
- Check that all the conditions listed as 'mandatory' for setting the CWS to 'Ready for QA' in the CWS policies are fulfilled.
- For features: create a testplan (we don't have a public process, nor any process for OOo-only features, for this yet)
- Check that all issues on the child workspace are really fixed and features are implemented as specified and announced.
- Run automated (testtool) tests to find regressions. Run at least the mandatory tests listed in the CWS policies. Run additional tests in functional areas touched by the CWS. Make sure the results are documented.
IMHO the qa project should start working on defining and documenting this in a way that makes experienced members of the qa project eligible as CWS QA Rep. But I have the impression that atm Sun QA still needs to be involved.
[Note: for CWS that concern build system issues, other people (community builders and Sun RE) need to be involved instead of QA, so that needs separate process.]
Ciao, Joerg
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
