NetarchiveSuite|
⇤ ← Revision 1 as of 2008-12-16 08:59:15
Size: 1682
Comment:
|
Size: 1741
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 6: | Line 6: |
| 1. via the tracker issue reporting process [[BR]] ... 1. via overview of fields for different tracker issues [[BR]] this includes what is displayed and editable both for user logged in and not logged in to GForge 1. via description of all fields that can appear in any tracker issue [[BR]] this includes explanation of field, description of possible values and default values. There are some differences between order of fields to be set for bugs, feature requests and patches respectively. Furthermore it may be that some of the fields are not included in all tracker issues. In the following these will be marked as: Values are marked with |
1. Reporting Process for tracker issues [[BR]] An overview of the tracker issue lifecycle is given and each part of the lifecycle is explained. 1. Fields that can appear in tracker issues [[BR]] An overview is given including what is displayed and editable both for user logged in and not logged in to GForge. [[BR]] All fields that can appear in any tracker issue are explaned including description of possible values and default values. There are some differences between order of fields to be set for bugs, feature requests and patches respectively. Furthermore it may be that some of the fields are not included in all tracker issues. In the following these will be marked as: Values are marked with |
Introduction
The NetarchiveSuite bug/feature-request/patch registration is done by tracker issues in GForge (https://gforge.statsbiblioteket.dk/tracker/?group_id=7)
The tracker issues are explained in three different ways:
Reporting Process for tracker issues BR An overview of the tracker issue lifecycle is given and each part of the lifecycle is explained.
Fields that can appear in tracker issues BR An overview is given including what is displayed and editable both for user logged in and not logged in to GForge. BR
All fields that can appear in any tracker issue are explaned including description of possible values and default values. There are some differences between order of fields to be set for bugs, feature requests and patches respectively. Furthermore it may be that some of the fields are not included in all tracker issues. In the following these will be marked as: Values are marked with
[TODO: For Version field, we need to find out whether this field should be used more extensively and what the rules then are for tracker issues found at reviews, in test, in production, in Scotland or somewhere else]
[TODO: For Status, check what invalid means for patches????]
[TODO: For Monitor value of Module field find better description]
[TODO: Write reporting processes]
[TODO: Write implementation processes]
[TODO: Remind tracker issue creater to report name if they are not users]
[TODO: Remind users to indicate "tracker issue status" for external tracker issues (they can only see open closed status)]
[TODO: Write work-around for non-users, if log-files where not attached when creating the tracker issue]
[TODO: Write tracker issue life-cycle]