ChildWorkSpace
Contents
What is a ChildWorkSpace?
A concept called ChildWorkSpaces (CWS) is used to organize changes to OpenOffice.org into smaller and independent units.
This page is intended as a first overview for end users. The wiki page "CWS" provides many more details for advanced contributors.
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 has all the details about each CWS, e.g. the list of tasks assigned to a CWS, its release target, the first milestone release where the CWS has been integrated, various testing results and the list of code changes.
The Process Flow
The relationship between an issue, a CWS and a release is described in this simplified process flow:
- someone finds a problem or has an enhancement idea
- the problem or the idea shouldn't be known in issuezilla yet
- a new issue is submitted
- the issue is confirmed/tested by testers and/or developers
- the issue is marked as "confirmed"
- development accepts an issue by marking it as "new"
- development creates a ChildWorkSpace
- development assigns some issues to the CWS's task list
- development solves the issue and tests the solution
- development commits the code changes into the CWS's code base
- development marks the issue as "fixed"
- development checks that the whole CWS works as expected
- development changes the CWS status to "Ready for QA"
- development reassigns the issues to testing
- testing checks for regressions and that the issues are solved
- tested issues are marked as "verified"
- testing changes the ChildWorkSpace status to "Approved by QA"
- "program management" changes the CWS status to "Nominated"
- "release engineering" integrates the code changes into a milestone release
- the CWS status is changed to "Integrated"
- the milestone containing some CWSes is released
- testing checks the issues again on the released version
- 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: there are a few steps inbetween, which all take their time: the fix has to be verified, integrated and then released
Q: which milestone release has the issue fixed?
A1: the EIS entry of a CWS provides this important detail (also all other details) A2: the closing comment of a fixed issue is supposed to mention the milestone A3: the milestone's release notes contains an extensive list of resolved issues