5432
Comment:
|
14407
|
Deletions are marked like this. | Additions are marked like this. |
Line 3: | Line 3: |
[[title(Bug/enhancement information guideline)]] | [[title(Bug/Feature Request/Patch Information Guideline)]] |
Line 9: | Line 9: |
The !NetarchiveSuite bug/enhancement 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/enhancement is listed and explained. In each header, it is indicated whether it can be set when a new bug/enhancement 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. |
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. |
Line 21: | Line 21: |
== Bug Information == |
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 == |
Line 25: | Line 40: |
Automatically set to '''''!NetarchiveSuite''''' | The project field in this context is automatically set to '''''!NetarchiveSuite'''''. |
Line 28: | Line 43: |
Automatically filled out with the person that submitted the bug/enhancement | The initials of the person which the tracker is submitted by is automatically set. |
Line 31: | Line 46: |
Automatically filled out with the date when the bug/enhancement was submitted (on form YYYY-MM-DD HH:MM) |
The date when the tracker was submitted is automatically set and given on form YYYY-MM-DD HH:MM. |
Line 35: | Line 49: |
Tells whether it is a bug or an enhancement. For new bugs/enhancements, it is automatically set to the selected tracker |
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 |
Line 39: | Line 52: |
* '''''Feature Requests''''' for enhancements | * '''''Feature Requests''''' for feature requests * '''''Patches''''' for patches with code sent !NetarchiveSuite for inclusion |
Line 42: | Line 56: |
=== Hardware: [new, edit] === Not used. Default is '''''None'''''. Should always be set to '''''None'''''. === Product: [new, edit] === The product that the bug/enhancement concern. Default is '''''None'''''. Should always set to '''''!NetarchiveSuite'''''. === Operating System: [new, edit] === Since the !NetarchiveSuite is independent on the operating system, this is not an information that is used. Default is '''''None'''''. Should always set to '''''All'''''. |
=== Hardware: [new, edit] (not for patches) === The hardware field is not used at the moment, and thus should never be set. Default is '''''None'''''. === Product: [new, edit] (not for patches) === The product that the tracker concerns will at this point only be !NetarchiveSuite. Thus the information is at this point '''''not''''' a necessity, but it should be set to '''''!NetarchiveSuite'''''. Default is '''''None'''''. === Operating System: [new, edit] (not for patches) === Since the !NetarchiveSuite is independent on the operating system, this is not an information that is used. - Thus it is '''''not''''' a necessity, but it should be set to '''''All'''''. Default is '''''None'''''. |
Line 64: | Line 72: |
Default is '''''None'''''. Should '''always''' be set to one of the following values * '''''common''''' if it concerns the !NetarchiveSuite common module * '''''deploy''''' * '''''documentation''''' * '''''general''''' * '''''harvester''''' * '''''harvestdefinitions''''' * '''''indexserver''''' * '''''logicalpreservation''''' * '''''monitor''''' * '''''releasetest''''' if it concerns the test description or the test set-up * '''''scripts''''' * '''''tools''''' * '''''viewerproxy''''' if it concerns the !NetarchiveSuite viewerproxy module |
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) * '''''arcrepository''''' [[BR]] if it concerns the archive repository part of the Archive module * '''''bitarchive''''' [[BR]] if it concerns the bit archive part of the Archive module * '''''bitpreservation''''' [[BR]] if it concerns the bit preservation part of 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 * '''''general''''' [[BR]] if it concerns general issues in the source or set-up * '''''harvester''''' [[BR]] if it concerns the the part of the Harvester module that do the actual harvesting * '''''harvestdefinitions''''' [[BR]] if it concerns the the part of the Harvester module where harvest definitions are specified * '''''indexserver''''' [[BR]] if it concerns the index server part of the Archive module * '''''logicalpreservation''''' [[BR]] if it concerns the logical preservation part of the Archive module * '''''monitor''''' [[BR]] if it concerns monitoring '''''[TODO: must be better described]''''' * '''''releasetest''''' [[BR]] if it concerns the test description or the test set-up * '''''scripts''''' [[BR]] if it concerns scripts for e.g. setting changes, database or simple harvest * '''''tools''''' [[BR]] if it concerns request for e.g. additionally tools that can assist in use of !NetarchiveSuite '''''[TODO: must be better described]''''' * '''''viewerproxy''''' [[BR]] if it concerns the !NetarchiveSuite viewerproxy (access) module * '''''external software''' (only for bugs)'' [[BR]] if it concerns external software (e.g. Heritrix) '''''[TODO: explain why only for bugs]''''' |
Line 82: | Line 97: |
Default is '''''None'''''. Version of code that the bug/enhancement relates to. Only set when it is important for reproduction of bug or understanding of enhancement. ''[Er det rigtigt? Og hvis ikke, hvad så når det er fundet i review? Skal man bare altid tage den seneste? – og hvordan ses så forskel på om den er fundet i produktion, test eller skotland?]'' === Severity: [new, edit] === Default is '''''None'''''. * '''''None''''' * '''''blocker''''' * '''''critical''''' * '''''major''''' * '''''normal''''' * '''''minor''''' * '''''trivial''''' * '''''enhancement''''' === Target Milestone: [new, edit] === Default is '''''None'''''. Should always set to '''''None'''''. |
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]''''' === Severity: [new, edit] (not for patches) === The severity is '''''only set when''''' the information is available. It may be at registration or it may be set later. Default is '''''None'''''. Must be set when information is available. * '''''None''''' [[BR]] if not set * '''''blocker''''' [[BR]] if the tracker blocks other developments * '''''critical''''' [[BR]] if the tracker is critical for the end-user * '''''major''''' [[BR]] if the tracker is a major problem for one or more parties * '''''normal''''' [[BR]] if it is a normal tracker where work-arounds can be made * '''''minor''''' [[BR]] if it is a minor tracker with only little implicaitons * '''''trivial''''' [[BR]] if it is trivial to solve the tracker * '''''enhancement''' (only for bugs)'' [[BR]] indicates that the data type of the bug must be changed to a feature request. === Target Milestone: [new, edit] (not for patches) === The target milestone s not used at the moment, and thus should never be set. Default is '''''None'''''. |
Line 107: | Line 125: |
Default is '''''None'''''. * '''''None''''' * '''''Fixed''''' * '''''Invalid''''' * '''''Not a bug''''' * '''''Duplicate''''' * '''''Won’t fix''''' * '''''No change''''' === Duplicate Of: [new, edit] === If the bug/enhancement is a duplicate then the '''''<number>''''' of the bug/enhancement that it is a duplicate of is written here. === URL: [new, edit] === Leave as empty. Not used ???? === Keywords: [new, edit] === * '''''None''''' * '''''ASSIGNMENT''''' * '''''PRIO_LIST''''' * '''''ESTIMATED''''' * '''''PLIGT''''' * '''''MISSING_REVIEW''''' * '''''MISSING_UNITTEST''''' * '''''TRIVIAL''''' |
The resolution field has different value sets for patches versus bugs and feature requests. ths 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 * '''''None''''' [[BR]] if not set * '''''Fixed''''' [[BR]] if the tracker is fixed with source checked into GForge. Note that this must be accopanied with update of the Status field to 'Resolved' * '''''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 * '''''Not a bug''''' [[BR]] if the behavior described is the intended behavior of the system '''''[TODO: describe more clearly the difference between this and Invalid]''''' * '''''Duplicate''''' [[BR]] if the tracker was already registerred and therefore are duplicate of another tracker * '''''Won’t fix''''' [[BR]] if it is decided not to fix the tracker ever * '''''No change''' (only for bugs)'' [[BR]] '''''[TODO: describe including expplanation of why only bugs has this value possible]''''' 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 contributer '''''[TODO: Find out whether we need one saying 'Incorparated' 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. |
Line 134: | Line 153: |
* '''''Open''''' * '''''Closed''''' * '''''Resolved''''' * '''''Assigned''''' * '''''Need Info''''' |
* '''''Open''''' [[BR]] * '''''Closed''''' [[BR]] * '''''Resolved''''' (not for patches) [[BR]] * '''''Assigned''''' (not for patches) [[BR]] * '''''Need Info''''' (not for patches) [[BR]] [TODO: more] === Keywords: [new, edit] (not for patches) === * '''''None''''' [[BR]] * '''''ASSIGNMENT''''' [[BR]] * '''''ESTIMATED''''' [[BR]] * '''''MISSING_REVIEW''''' [[BR]] * '''''MISSING_UNITTEST''''' [[BR]] * '''''PLIGT''''' [[BR]] * '''''PRIO_LIST''''' [[BR]] * '''''TRIVIAL''''' [[BR]] |
Line 145: | Line 176: |
[TODO: a little more] |
|
Line 146: | Line 179: |
The priority can only be changed by QA in coorporation 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 invironment. |
|
Line 147: | Line 182: |
[TODO: more --- and can we set it initially?] |
|
Line 153: | Line 190: |
1. '''''highest | 1. '''''highest''''' |
Line 156: | Line 194: |
A short description of the bug/enhancement. | The summary consist 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. |
Line 159: | Line 198: |
Describe * what the bug/enhancement is about * possible resolutions * estimated time for fixing |
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. Furtehremore 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. === 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 |
Line 165: | Line 233: |
Not used ??? | This field is not used at the moment, and thus should never be set. |
Line 168: | Line 236: |
Extra comments relating to description | This field is used to enter additional comments to the Detailed description. |
Line 171: | Line 239: |
List of historical description and comments to the bug/enhancement. | List of additional comments to description of the tracker. See also explation of the 'Detailed Description' field. |
Line 174: | Line 242: |
This field offers functionality to add attached files to the list of files under the 'Existing Files' field. | |
Line 176: | Line 245: |
List of files already attached to the bug/enhancement | List of files already attached to the tracker. |
Line 179: | Line 248: |
Log of changes already made to the bug/enhancement | Log of changes already made to the tracker. |
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 is 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 needs to be set again.
Hardware: [new, edit] (not for patches)
The hardware field is not used at the moment, and thus should never be set.
Default is None.
Product: [new, edit] (not for patches)
The product that the tracker concerns will at this point only be NetarchiveSuite. Thus the information is at this point not a necessity, but it should be set to NetarchiveSuite.
Default is None.
Operating System: [new, edit] (not for patches)
Since the NetarchiveSuite is independent on the operating system, this is not an information that is used. - Thus it is not a necessity, but it should be set to All.
Default is None.
Component: [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)
arcrepository BR if it concerns the archive repository part of the Archive module
bitarchive BR if it concerns the bit archive part of the Archive module
bitpreservation BR if it concerns the bit preservation part of 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
general BR if it concerns general issues in the source or set-up
harvester BR if it concerns the the part of the Harvester module that do the actual harvesting
harvestdefinitions BR if it concerns the the part of the Harvester module where harvest definitions are specified
indexserver BR if it concerns the index server part of the Archive module
logicalpreservation BR if it concerns the logical preservation part of the Archive module
monitor BR if it concerns monitoring [TODO: must be better described]
releasetest BR if it concerns the test description or the test set-up
scripts BR if it concerns scripts for e.g. setting changes, database or simple harvest
tools BR if it concerns request for e.g. additionally tools that can assist in use of NetarchiveSuite [TODO: must be better described]
viewerproxy BR if it concerns the NetarchiveSuite viewerproxy (access) module
external software (only for bugs) BR if it concerns external software (e.g. Heritrix) [TODO: explain why only for bugs]
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]
Severity: [new, edit] (not for patches)
The severity is only set when the information is available. It may be at registration or it may be set later.
Default is None.
Must be set when information is available.
None BR if not set
blocker BR if the tracker blocks other developments
critical BR if the tracker is critical for the end-user
major BR if the tracker is a major problem for one or more parties
normal BR if it is a normal tracker where work-arounds can be made
minor BR if it is a minor tracker with only little implicaitons
trivial BR if it is trivial to solve the tracker
enhancement (only for bugs) BR indicates that the data type of the bug must be changed to a feature request.
Target Milestone: [new, edit] (not for patches)
The target milestone s not used at the moment, and thus should never be set.
Default is None.
Resolution: [new, edit]
The resolution field has different value sets for patches versus bugs and feature requests. ths 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
None BR if not set
Fixed BR if the tracker is fixed with source checked into GForge. Note that this must be accopanied with update of the Status field to 'Resolved'
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
Not a bug BR if the behavior described is the intended behavior of the system [TODO: describe more clearly the difference between this and Invalid]
Duplicate BR if the tracker was already registerred and therefore are duplicate of another tracker
Won’t fix BR if it is decided not to fix the tracker ever
No change (only for bugs) BR [TODO: describe including expplanation of why only bugs has this value possible]
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 contributer
[TODO: Find out whether we need one saying 'Incorparated' 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.
Status: [new, edit]
Default is Open.
Open BR
Closed BR
Resolved (not for patches) BR
Assigned (not for patches) BR
Need Info (not for patches) BR
[TODO: more]
Keywords: [new, edit] (not for patches)
None BR
ASSIGNMENT BR
ESTIMATED BR
MISSING_REVIEW BR
MISSING_UNITTEST BR
PLIGT BR
PRIO_LIST BR
TRIVIAL BR
Assigned To: [new, edit]
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: a little more]
Priority: [new, edit]
The priority can only be changed by QA in coorporation 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 invironment.
Default is 3.
[TODO: more --- and can we set it initially?]
Normally it will only be the administrator (QA) that changes the priority to one of the following values:
The summary consist of a short description of the tracker. The summary is used when an overview of tracker is made. This information
The detailed description adds information as basis for planning and doing resolution of the tracker. This information The detailed description must include
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.
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. === 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.
This field is not used at the moment, and thus should never be set.
This field is used to enter additional comments to the Detailed description.
List of additional comments to description of the tracker. See also explation of the 'Detailed Description' field.
This field offers functionality to add attached files to the list of files under the 'Existing Files' field.
List of files already attached to the tracker.
Log of changes already made to the tracker.
lowest Summary: [new, edit]
Detailed description: [new, edit]
URL: [new, edit] (not for patches)
Found In: [new, edit] (only for bugs)
Unit test BR if found in unit test made on involved code
Unit test BR if it should have been found in unit test made on involved code Use Canned Response: [edit]
OR Attach A Comment: [edit]
Followup:
Attach Files: [new, edit]
Existing Files:
Change Log: