Difference between revisions of "ChildWorkSpace"
(FAQ: which milestone has the fix?) |
m (minor cleanups) |
||
| 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]]). | |
== How does it relate to Issues == | == How does it relate to Issues == | ||
| − | OpenOffice.org's code base may be changed as a result of | + | 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]]. |
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)]]. 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 Process Flow == | ||
| Line 14: | Line 16: | ||
# someone finds a problem or has an enhancement idea | # someone finds a problem or has an enhancement idea | ||
# he checks that the problem or the idea are new | # 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 confirmed/tested by testers and/or developers | ||
# the issue is marked as "confirmed" | # the issue is marked as "confirmed" | ||
| Line 25: | Line 27: | ||
# development changes the CWS status to "Ready for QA" | # development changes the CWS status to "Ready for QA" | ||
# testing checks for regressions and that the issues are solved | # testing checks for regressions and that the issues are solved | ||
| − | # tested issues are marked as verified | + | # tested issues are marked as "verified" |
# testing changes the ChildWorkSpace status to "Approved by QA" | # testing changes the ChildWorkSpace status to "Approved by QA" | ||
# "program management" changes the ChildWorkSpace status to "Nominated" | # "program management" changes the ChildWorkSpace status to "Nominated" | ||
Revision as of 15:04, 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 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:
- 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: 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
