Difference between revisions of "ChildWorkSpace"
(the original CWS page is completely incomprehensible for end users => start something better) |
(FAQ: which milestone has the fix?) |
||
| Line 36: | Line 36: | ||
== Frequently Asked Questions == | == 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 | 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 | ||
Revision as of 14:27, 15 August 2008
Contents
What is a ChildWorkSpace
A ChildWorkSpace (CWS) is a concept used to organize changes to OpenOffice.org's code base into smaller and independent units.
How does it relate to Issues
OpenOffice.org's code base may be changed as a result of "issues", which may be defect reports, enhancement requests or feature requests. OpenOffice.org's issues are managed in 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.
The Process Flow
The relationship between an issue, a CWS and a release can be described as this idealized process flow:
- someone finds a problem or has an enhancement idea
- he checks that the problem or the idea are new
- the user files an issue
- 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
- the corresponding code changes are applied into the CWS's code base
- development marks the issue as "fixed"
- development checks that the changed CWS works as expected
- development changes the CWS status to "Ready for QA"
- 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 ChildWorkSpace status to "Nominated"
- "release engineering" integrates the code changes into a milestone release
- the ChildWorkSpace status is changed to "Integrated"
- the milestone 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: 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
