Difference between revisions of "ChildWorkSpace"

Revision as of 15:59, 20 August 2008

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:

1. someone finds a problem or has an enhancement idea
2. the problem or the idea shouldn't be known in issuezilla yet
3. a new issue is submitted
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. development solves the issue and tests the solution
10. development commits the code changes into the CWS's code base
11. development marks the issue as "fixed"
12. development checks that the whole CWS works as expected
13. development changes the CWS status to "Ready for QA"
14. development reassigns the issues to testing
15. testing checks for regressions and that the issues are solved
16. tested issues are marked as "verified"
17. testing changes the ChildWorkSpace status to "Approved by QA"
18. "program management" changes the CWS status to "Nominated"
19. "release engineering" integrates the code changes into a milestone release
20. the CWS status is changed to "Integrated"
21. the milestone containing some CWSes is released
22. testing checks the issues again on the released version
23. testing marks the issues as "closed"

Frequently Asked Questions

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?

• there are a few steps which all take their time:
  • the list of all the issues in the CWS has to be solved
  • the fixes have to be verified
  • the CWS must be integrated
  • the milestone has to be released

which milestone release has the issue fixed?

• the EIS entry of a CWS provides this important detail (also all other details) and you can Find a CWS by directly by entering it´s issue.
• the closing comment of a fixed issue is supposed to mention the milestone
• the milestone's release notes contains an extensive list of resolved issues