Difference between revisions of "ChildWorkSpace"
m (→What is a ChildWorkSpace?) |
(→The Process Flow) |
||
| Line 15: | Line 15: | ||
== The Process Flow == | == The Process Flow == | ||
| − | The relationship between an issue, a CWS and a release | + | 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 | # 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 confirmed/tested by testers and/or developers | ||
# the issue is marked as "confirmed" | # the issue is marked as "confirmed" | ||
| Line 24: | Line 24: | ||
# development creates a ChildWorkSpace | # development creates a ChildWorkSpace | ||
# development assigns some issues to the CWS's task list | # development assigns some issues to the CWS's task list | ||
| − | # the | + | # 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 marks the issue as "fixed" | ||
| − | # development checks that the | + | # development checks that the whole CWS works as expected |
# development changes the CWS status to "Ready for QA" | # 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 | # 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 | + | # "[[Program_Management|program management]]" changes the CWS status to "Nominated" |
| − | # "release engineering" integrates the code changes into a milestone release | + | # "[[Release_Engineering|release engineering]]" integrates the code changes into a milestone release |
| − | # the | + | # the CWS status is changed to "Integrated" |
| − | # the milestone is released | + | # the milestone containing some CWSes is released |
# testing checks the issues again on the released version | # testing checks the issues again on the released version | ||
# testing marks the issues as "closed" | # testing marks the issues as "closed" | ||
Revision as of 09:28, 16 August 2008
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
