db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dag.Wan...@Sun.COM (Dag H. Wanvik)
Subject Re: Jira field definitions
Date Tue, 16 Jun 2009 14:33:06 GMT

Hi all,

I enclose a proposed overhaul of the Jira fields to ease our bug
triaging.  There are changes on several levels:

- Update documentation for some fields 
- Add some fields
- Modifying some fields
- Merging or (re)moving some fields
- Stop using some field values (we can't modify fields we share with
  other users of our JIRA installation)

I have tried to incorporate comments I have seen so far, but I'm sure
I missed some things, so please add your comments and I'll try to fix
it. I will update "Tips for filing Apache Derby Bugs" to reflect our
conclusions, if we reach any ;-) I don't document every field here,
only the ones which I find non-obvious or that we have been

I use the following format below:

<field name> : <type>
Doc: <documentation>
Comment: <discussion comments, rationale, questions>


Issue type : {Bug, Improvement, Task, Sub-task}
Doc: Use "bug" if the the issue concerns wrong product functionality. Use
"improvement" for all product enhancements that can not be classified
as bugs. Use "task" for process issues, e.g. work with releases. 
All the three issue types can have sub-task issue types.

Comment: We will not use "Wish", "New Feature", and "Test" issue
types. Use "Improvement" where you previously used New Feature. The
rationale for the merge is that it is hard to use these two issue
types consistently, and they often overlap.

Summary: String
      - Make as descriptive as possible, but try to avoid using very
        long lines. It's usually better to give more detail in the
      - For bugs, describe the problem or symptom seen, not its solution.
      - Use of keywords in the title is good, to the extent they do not
        duplicate component information. 
Comment: no changes

Priority: {Blocker, Critical, Major, Minor, Trivial}

Doc: This is technical severity and not really a priority (see Urgency
field for that property).  Think of these values as severity 1 (trivial;
least severe) to severity 5 (most severe: blocker). Typically, this
field will not change unless more information about the bug becomes
available from investigation or from customers. Its value is normally
not changed by release and scheduling decisions. Not that users
reporting bugs are liable to interpret this field as priority for
themselves, so developers should be careful to explain why we change
the value when we do. The value should reflect how hard is is to live
with Derby ("hassle") as long as this bug exists. Some key questions in
when trying to set this value (reflecting approximate decreasing severity)

     - Is data corrupted?
     - Is data lost?
     - Is a crash involved (reduced availability of data)?
     - Wrong query results?  
     - performance unexpectedly low?
     - Is a work-around possible?
     - Is it merely a nuisance?

Comment: Unfortunately, we can't change the name or the the values as
long as we share JIRA installations with other Apache projects.
Five levels of severity may be too much, but since we are stuck with
the values we might as well use accept that they will be used.

Urgency: {None, blocker, urgent, normal, low} 

Doc: This is the field used for dynamically reflecting scheduling
opinions and decisions; when a release manager is appointed, typically
a release manager will "own" this field to reflect how she sees how
issues should be prioritized for fixing prior to a release
("releasability"). Presumably, no release will be made if there is a
"blocker" left. This field also takes likelihood of users hitting a
bug into account; Priority a.k.a. Severity does not.  After triage, no
bug should have the "none" urgency.

Comment: What is the relationship between this field and High Value
Fix flag? Could it subsume High Value Fix?

Due date: Date
Doc: not used

Components: {Unknown, 
             Build tools,
             Eclipe plug-in,
             Network Client,
             Network Server,
             Web site}
Doc: After bug triage, no issue should have the "unknown" component.
     Several components can be selected to express a "and"
     relationship, e.g. "Test" && "Store".
     "Localization" includes "internationalization".

Comment: Newcomer moved to Bug Behavior Facts check-boxes
         Performance moved to Bug Behavior Facts check-boxes
         Regression Test Failure moved to Bug Behavior Facts check-boxes
         Security moved to Bug Behavior Facts check-boxes

Affects version: {Unknown, Released versions, Unreleased versions}
Comment: no changes

Fix version: {Unknown, Unreleased versions, Released versions}
Comment: no changes

Assignee: DeveloperName
Doc: To assign yourself to an issue you need to be registered as a
     developer. Ask one of the committers about this on the mailing
     list derby-dev@db.apache.org

Comment: This fields serves two functions, it synchronizes work so
         that two people can avoid working on the same issue, and
         second, it allows due credit to be reflected after the work
         is done. If there is more than one person contributing to the
         work, the main contributor will be the one assigned.

Environment: String
Doc: For example operating system, software platform and/or hardware
     specifications (include as appropriate for the issue), including:
     - JRE version
     - Output of org.apache.derby.tools.sysinfo (derby version info)
Comment: no changes

Description: String
Doc: Should be used to give all possible details of the issue in
     question.  If the issue you are filing is a bug, please include
     the following details in this field:

     - How to reproduce the bug (either step-by-step information or
       attach a reproduction script/program)
     - Chained nested exceptions reported by Derby and the SQLSTATE
       reported by the system
     - In a client/server scenario, also include any stack trace found
       in derby.log if available.


Original Estimate: *w *d *h *m
Doc: Not currently used

Derby issue & fix info: boolean check-boxes
     High value fix
     Known fix
     Patch available
     Release note needed
     Repro attached
     Workaround exists
Doc: These yes/no check boxes relate to process 
     High value fix: This issue represents a potentially high return
                     on time investment based on:

                     - Frequency and likelihood the issue might be hit
                     by users.
                     - Estimated difficulty of fix.
                     - Risk to existing users if the fix is
                     - Severity of the issue (see "Priority" field")
                     - Availability of a workaround (see also "repro
                     attached" check box)
                     - The amount of user/developer time is wasted by
                     the issue.
     Known fix: A comment describing a possible fix exists
     Newcomer: An issue suitable for a newcomer to Derby
     Patch available: A patch is available for this issue. This is
                      normally a sign that a code review is desired.

     Release note needed: The fix that went into the code changes
                          Derby's behavior, so that it may break
                          existing applications, or otherwise warrants
                          the user's attention.
                          Before the issue is resolved as fixed there
                          should exist an attached "releaseNote.html"
                          file in the proper format.

     Repro attached: The bug can be reproduced with code or steps
                          in a description attached to the issue or
                          described in the comments.
     Workaround attached: A described workaround can be found in the
                          issue, either in the comments or in an
Comment: Renamed "Derby info" to "Derby issue & fix info" to distinguish
     from Bug Behavior Facts.
     Added "Repro attached" and "Workaround attached" and "known fix".
     Removed "Existing application impact".
     Can we merge the semantics of "High value fix" into "Urgency"
     Moved "Newcomer" here from "Bug Behavior Facts".
     Is "workaround attached" useful? (suggested by me)
     Is "known fix" useful? (suggested by Knut)

Bug behavior facts: boolean check-boxes
     Data corruption
     Deviation from standard
     Embedded/client difference
     Regression test failure
     Seen in production
     Wrong query result

Doc: The Bug Behavior Facts contain additional yes/no check-box
     characterization of the issue.
     Crash: Total loss of functionality. What this means depends on
            the Component. For example, for the database engine, it
            means it needs to be rebooted. For the ij tool, it could
            be a hang.  For the network server it could mean it does
            not answer or hand out new connections.
     Data corruption
     Deviation from standard
     Embedded/client difference
     Regression: A bug that was not present in some previous publicly
                 available release.
     Regression test failure
     Seen in production: The bug is observed in existing
                          application code ("in the wild").
     Wrong query result

Comment: Renamed to "Bug behavior facts:" from Categories.
         Moved "regression" here from "derby issue & fix info". Moved
         "Newcomer" to Derby issue & fix info.
         Added "seen in production".
         Is "seen in production" useful (suggested by Myrna)

View raw message