ChildWorkSpace

What is a ChildWorkSpace

Changes to OpenOffice.org's code base are organized into smaller and independent units by a concept called ChildWorkSpaces (CWS).

How does it relate to Issues

OpenOffice.org's code base may be changed as a result of Issues, which can be classified as defect reports, enhancement requests or feature requests. Issues are managed in a tool called issuezilla.

Related issues get grouped together and are assigned to a CWS. The resulting code change consists of bug fixes, enhancements and feature implementations that correspond to the list of issues registered for that CWS.

ChildWorkSpaces are managed in a tool called Environment Information System (EIS). It shows the list of tasks to a CWS, the release target, the code changes and the first milestone release where the CWS has been integrated.

The Process Flow

The relationship between an issue, a CWS and a release can be described as this idealized process flow:

1. someone finds a problem or has an enhancement idea
2. he checks that the problem or the idea are new
3. he files an issue
4. the issue is confirmed/tested by testers and/or developers
5. the issue is marked as "confirmed"
6. development accepts an issue by marking it as "new"
7. development creates a ChildWorkSpace
8. development assigns some issues to the CWS's task list
9. the corresponding code changes are applied into the CWS's code base
10. development marks the issue as "fixed"
11. development checks that the changed CWS works as expected
12. development changes the CWS status to "Ready for QA"
13. testing checks for regressions and that the issues are solved
14. tested issues are marked as "verified"
15. testing changes the ChildWorkSpace status to "Approved by QA"
16. "program management" changes the ChildWorkSpace status to "Nominated"
17. "release engineering" integrates the code changes into a milestone release
18. the ChildWorkSpace status is changed to "Integrated"
19. the milestone is released
20. testing checks the issues again on the released version
21. testing marks the issues as "closed"

Frequently Asked Questions

Q: why is there a delay between the developer marking an issue as "fixed" and the availability of a milestone release, which has the fix integrated?

 A: the fix has to be verified, integrated and released all of which take their time

Q: in which milestone release is the issue fixed?

 A1: the closing comment of a fixed issue is supposed to mention the milestone
 A2: the milestone's release notes contains an extensive list of resolved issues