Difference between revisions of "ChildWorkSpace"
m (minor cleanups) |
m |
||
Line 1: | Line 1: | ||
− | == What is a 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]]). | + | Changes to [[OpenOffice.org]]'s code base are organized into smaller and independent units by a concept called <b>ChildWorkSpaces</b> ([[CWS]]). |
− | == How does it relate to Issues == | + | == 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_Report|defect reports]], [[Enhancement_Request|enhancement requests]] or [[Feature_Request|feature requests]]. Issues are managed in a tool called [[Issuezilla | issuezilla]]. | OpenOffice.org's code base may be changed as a result of [[Issues]], which can be classified as [[Defect_Report|defect reports]], [[Enhancement_Request|enhancement requests]] or [[Feature_Request|feature requests]]. Issues are managed in a tool called [[Issuezilla | issuezilla]]. | ||
Line 9: | Line 9: | ||
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. | 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 [[EIS|Environment Information System (EIS)]] | + | ChildWorkSpaces are managed in a tool called [[EIS|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 Process Flow == | ||
Line 39: | Line 39: | ||
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? | 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 | + | A: there are a few steps inbetween, which all take their time: the fix has to be verified, integrated and then released |
− | Q: | + | Q: which milestone release has the issue fixed? |
− | A1: the closing comment of a fixed issue is supposed to mention the milestone | + | A1: the EIS entry of a CWS provides this important detail (also <b>all</b> 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 |
Revision as of 15:16, 15 August 2008
Contents
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 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 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
- he 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: 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