NetarchiveSuite|
Size: 13905
Comment:
|
Size: 11385
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 84: | Line 84: |
| * '''''New''''' [[BR]] if not set * '''''Need Info''''' [[BR]] The tracker needs additional informaiton before the real problem can be identified. * '''''Evaluated ''''' [[BR]] The tracker needs additional informaiton before the real problem can be identified. * '''''In progress''''' [[BR]] if the tracker is not valid as a bug or feature request, e.g. if it was caused by wrong use of the system * '''''Fixed''''' [[BR]] if the tracker is fixed with source checked into GForge. Note that this must be accompanied with update of the 'Status' field to 'Resolved' * '''''Fixed, Passed QA''''' [[BR]] if the tracker is fixed with source checked into GForge. Note that this must be accompanied with update of the 'Status' field to 'Resolved * '''''Fixed, Released''''' [[BR]] if the tracker is fixed with source checked into GForge. Note that this must be accompanied with update of the 'Status' field to 'Resolved * '''''Duplicate''''' [[BR]] if the tracker was already registered and therefore are duplicate of another tracker |
* '''''New''''' [[BR]] if new and not set * '''''Need Info''''' [[BR]] The tracker needs additional informaiton before the real problem can be identified. Informaiton about what sort of information is needed must be noted in the 'Detailed description' field or in the 'Followup' field (via 'OR Attach A Comment') * '''''Evaluated ''''' [[BR]] if the tracker is evaluated estimated as preparation for prioritisation of when the tracker can be implemented. The estimate must be noted in the 'Detailed description' field or in the 'Followup' field (via 'OR Attach A Comment') * '''''In progress''''' [[BR]] if the tracker is being implemented. That means the process of programming, documentation, unit test development and code reviews has started and no other developer should interfear without coordinating first. * '''''Fixed''''' [[BR]] if the tracker is fixed with source and unit tests checked into GForge, and after sanity test and code review. Note that the description of how it is implemented and check e.g. in unit test must be noted in the 'Detailed description' field or in the 'Followup' field (via 'OR Attach A Comment'). * '''''Fixed, Passed QA''''' [[BR]] if QA has accepted the tracker as fixed. Only QA must change to this status. Before a release test all trackers included must have this status before the release test can start. * '''''Fixed, Released''''' [[BR]] if the tracker has been release tested and the implementation is part of a stable release. * '''''Duplicate''''' [[BR]] if the tracker was already registered and therefore are duplicate of another tracker. The duplicate tracker number must then be noted in the 'Duplicate Of' field. |
| Line 106: | Line 104: |
| If the tracker is a duplicate then the '''''<number>''''' of the tracker that it is a duplicate of is written here. | If the tracker is a duplicate then the '''''<number>''''' of the tracker that it is a duplicate of is written here. The status must then be set to Duplicate. |
| Line 108: | Line 106: |
| === Status: [new, edit] === === Keywords: [new, edit] (not for patches) === * '''''None''''' [[BR]] if not set * '''''ASSIGNMENT''''' [[BR]] if an assignment has to be made on the tracker before further progress can be initiated * '''''ESTIMATED''''' [[BR]] if the tracker is estimated as preparation for prioritisation of when the tracker can be resolved. Note that if this keyword is highlighted, the estimate needs to be noted in the 'Detailed description' field or in the 'Followup' field (via 'OR Attach A Comment') * '''''MISSING_REVIEW''''' [[BR]] if the tracker is resolved, but the resolution of the tracker is still not reviewed * '''''MISSING_UNITTEST''''' [[BR]] if the tracker is resolved, but there have not been made unit-tests for the resolution of the tracker * '''''PLIGT''''' [[BR]] if the tracker has special interest of being resolved by the Danish NetarchiveSuite users * '''''PRIO_LIST''''' [[BR]] if the tracker is subject of being put in to the top priority list of trackers to be solved in the next iterations * '''''TRIVIAL''''' [[BR]] if the tracker is trivial to resolve and thus could be taken in short breaks from other tasks |
|
| Line 152: | Line 140: |
| === URL: [new, edit] (not for patches) === The URL field is optional. It can be used to specify an URL of interest for the tracker, but in most cases this information will be in the 'Detailed Description' or 'Followup' of the tracker. === Found In: [new, edit] (only for bugs) === This field is used to register where the bug was found. The information is used for registration of statistics of bugs, which can assist in adjusting procedures for bug fixing. For instance if a bug is found in production, but obviously should have been found in a code review, this would be an indication that there should be more focus on code reviews. * '''''Unit test''''' [[BR]] if found in unit test made on involved code * '''''Code review''''' [[BR]] if found in code review of the involved code * '''''Release test''''' [[BR]] if found in release test of the involved code * '''''Production''''' [[BR]] if found in running production code '''''[TODO: Add Sanity test in GForge and here, and maybe make specification of which production code we refer to (Danish, Scottish ...)]''''' === Should Have Been Found In: [new, edit] (only for bugs) === This field is used to register where the bug should have been found. The information is used for registration of statistics of bugs, which can assist in adjusting procedures for bug fixing. For instance if a bug is found in production, but obviously should have been found in a code review, this would be an indication that there should be more focus on code reviews. * '''''Unit test''''' [[BR]] if it should have been found in unit test made on involved code * '''''Code review''''' [[BR]] if it should have been found in code review of the involved code * '''''Release test''''' [[BR]] if it should have been found in release test of the involved code * '''''Production''''' [[BR]] if it should have been found in running production code * '''''Sanity test''''' [[BR]] if it should have been found in sanity made by developer before code review |
title(Bug/Feature Request/Patch Information Guideline)
Introduction
The NetarchiveSuite bug/feature-request registration is done by trackers in GForge (https://gforge.statsbiblioteket.dk/tracker/?group_id=7)
In the next section all headers that can appear in a bug/feature-request/patch (from here called tracker) is listed and explained.
In each header, it is indicated whether it can be set when a new tracker is created (by [new]) and whether it is editable when information is changed (by [edit]). No indication means that it is information calculated by GForge.
For each header the following information is given, if relevant:
- explanation
- default value
- values it should be set to
- possible values with explanation
- time when information should be updated
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 trackers. In the following these will be marked as: Values are marked with
(not for bugs) if the field is not included in bug trackers
(not for feature requests) if the field is not included in feature request trackers
(not for patches) if the field is not included in patch trackers
Nothing is indicated the field in included for all trackers.
There are also differences in possible values in drop downs for the different trackers. Values are marked with
(bugs only) if it only concerns bug trackers
(feature requests only) if it only concerns feature request trackers
(patches only) if it only concerns patch trackers
Nothing is indicated if the values are possible for all trackers.
Bug/Feature Request/Patch Information
For project:
The project field in this context is automatically set to NetarchiveSuite.
Submitted By:
The initials of the person which the tracker is submitted by are automatically set.
Date Submitted:
The date when the tracker was submitted is automatically set and given on form YYYY-MM-DD HH:MM.
Data Type: [edit]
The data type tells whether it is a bug, a feature request or a patch. For new bugs/feature-requests/patches, it is automatically set to the selected tracker
Bugs for bugs
Feature Requests for feature requests
Patches for patches with code sent NetarchiveSuite for inclusion
NOTE: if the data type is changed, there may be some of the values that are not transferred to the new tracker type. These values need to be set again.
Module: [new, edit]
This component field must be set in order to have the tracker directed to the correct tracker owner.
Default is None.
Must always be set to one of the following values for NetarchiveSuite
None BR if not set (which it must be before it is assigned to a person)
Access BR if it concerns the Access (viewerproxy) module
Archive BR if it concerns the Archive module
Common BR if it concerns the Common module
Deploy BR if it concerns the Deploy module
Documentation BR if it concerns the documentation related to NetarchiveSuite
Harvester BR if it concerns the Harvester module
Monitor BR if it concerns monitoring [TODO: must be better described]
Test BR if it concerns the test of NetarchiveSuite
Version: [new, edit]
The version field is only used, when it is critical in order to understand the tracker or reproduce a bug. Version of code that the tracker relates to. This means that it must for patches, since these will include code that need to be compatible with the rest of the code.
Default is None.
[TODO: We need to find out whether this field should be used more extensively, and what the rules then are for trackers found at reviews, in test, in production, in Scotland or somewhere else]
Status: [new, edit]
The status tells where the tracker is in the resolution process. The process allways starts by an open tracker and ends with a closed tracker.
The status field has different value sets for patches versus bugs and feature requests. The reason is that the patches includes code that fixes the problem, and thus the resolution concerns the patch itself rather than the problem which is the focus for a bug or a feature request. The resolution field must be set during the process of treating the tracker.
Default is None.
Resolution values for bugs and feature requests which must be set during process of treating the tracker
New BR if new and not set
Need Info BR The tracker needs additional informaiton before the real problem can be identified. Informaiton about what sort of information is needed must be noted in the 'Detailed description' field or in the 'Followup' field (via 'OR Attach A Comment')
Evaluated BR if the tracker is evaluated estimated as preparation for prioritisation of when the tracker can be implemented. The estimate must be noted in the 'Detailed description' field or in the 'Followup' field (via 'OR Attach A Comment')
In progress BR if the tracker is being implemented. That means the process of programming, documentation, unit test development and code reviews has started and no other developer should interfear without coordinating first.
Fixed BR if the tracker is fixed with source and unit tests checked into GForge, and after sanity test and code review. Note that the description of how it is implemented and check e.g. in unit test must be noted in the 'Detailed description' field or in the 'Followup' field (via 'OR Attach A Comment').
Fixed, Passed QA BR if QA has accepted the tracker as fixed. Only QA must change to this status. Before a release test all trackers included must have this status before the release test can start.
Fixed, Released BR if the tracker has been release tested and the implementation is part of a stable release.
Duplicate BR if the tracker was already registered and therefore are duplicate of another tracker. The duplicate tracker number must then be noted in the 'Duplicate Of' field.
Invalid BR if the tracker is not valid as a bug or feature request, e.g. if it was caused by wrong use of the system
Won’t fix BR if it is decided not to fix the tracker ever, for instance if the behavior described is the intended behavior of the system
Resolution values for patches which must be set during process of treating the patch
None BR if not set
Accepted BR if the patch is accepted for inclusion in the NetarchiveSuite source
Rejected BR if the patch is rejected, and therefore will stay out of the NetarchiveSuite source
Out of date BR if the patch has already been solved by other corrections
Awaiting response BR if there are missing decision of accept or rejection and answer to contributor
[TODO: Find out whether we need one saying 'Incorporated' indicating that the code is not only accepted but also included in next release]
Duplicate Of: [new, edit] (not for patches)
If the tracker is a duplicate then the <number> of the tracker that it is a duplicate of is written here. The status must then be set to Duplicate.
Assigned To: [new, edit]
The person the tracker is assigned to. That means it is this person that will be responsible for next action on the tracker (except from points where QA needs to take action). A tracker can be assigned to a person either via the component specification which each has a responsible person for the component. Or it can be assigned by the person themselfes, in case they want to take it, or it can be reassigned by the allready assigned person or QA.
Default is Nobody.
Nobody in case the bug/enhancement is not assign to anybody
The <name> of the person that the bug/enhancement is assign to
[TODO: There appers a value 'No Change on trackers that has Lars Clausen on as the assigned person. Either this value should be explained or the trackers needs reassignment]
Priority: [new, edit]
The priority can only be changed by QA in cooperation with the daily production manager. The priority is basis for planning resolution order of tracker and which procedures can be used in order to have fixes quickly patched into the production environment.
Default is 3.
Normally it will only be the administrator (QA) that changes the priority to one of the following values:
1 the lowest priority a tracker can have, the tracker will most likely be feature requests and has little change of becomming resolved unlees they are trivial to solve
2 thrackers with this priority will most likely be feature requests
3 the middle priority is the default priority
4 Trackers with this priority will in most cases be fixed within the next iteration
5 the highest priority a trackers can have, - these trackers are the only trackers that can initiate production patches, and fixes under release test.
[TODO: make more clear descriptions, if possible]
Summary: [new, edit]
The summary consists of a short description of the tracker. The summary is used when an overview of tracker is made. This information must be provided when the tracker is registered.
Detailed description: [new, edit]
The detailed description adds information as basis for planning and doing resolution of the tracker. This information must be provided as detailed as possible at the time of registering the tracker. Furthermore it is used to add information at later stages. Additional comments must be entered via the 'OR Attach A Comment' field and they will then appear in the 'Followup' field.
The detailed description must include
- a detailed description of what the tracker is about
- possible resolutions if known
- estimated time for fixing in case the Keywords field includes setting of the ESTIMATED keyword.
Use Canned Response: [edit]
This field is not used at the moment, and thus should never be set.
OR Attach A Comment: [edit]
This field is used to enter additional comments to the 'Detailed description' field.
Followup:
List of additional comments to 'Detailed description' of the tracker. See also explanation of the 'Detailed Description' field.
Attach Files: [new, edit]
This field offers functionality to add attached files to the list of files under the 'Existing Files' field.
Existing Files:
List of files already attached to the tracker.
Change Log:
Log of changes already made to the tracker.