db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Re: Jira field definitions
Date Tue, 16 Jun 2009 18:39:18 GMT
Dag H. Wanvik wrote:
> Hi all,
> I enclose a proposed overhaul of the Jira fields to ease our bug
> triaging. 
Thanks Dag. Comments in-line.
>  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
> discussing.
> I use the following format below:
> <field name> : <type>
> Doc: <documentation>
> Comment: <discussion comments, rationale, questions>
> Dag
> -----------------------------------------------------
> Issue type : {Bug, Improvement, Task, Sub-task}
> Doc: Use "bug" if the the issue concerns wrong product 
or test
> 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
> Doc: 
>       - Make as descriptive as possible, but try to avoid using very
>         long lines. It's usually better to give more detail in the
>         description.
>       - 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). 
Perhaps it is just what I am used to but I tend to think of a Severity 1 
as a blocker down to Severity 5 as trivial.

> Typically, this
> field will not change unless more information about the bug becomes
> available from investigation or from customers. 
I would replace customers with users.
> 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?
I think it could, but there are fairly hard issues like DERBY-700 and 
DERBY-1433 which may not have a high urgency with regard to a specific 
release but are very important because they are ticking time bombs or 
bombs that have already gone off.   These issues might have a higher 
urgency for 10.6 than 10.5.2 but development is going on for both and we 
don't have a release manager for 10.6 yet, so how should they be 
evaluated in terms of Urgency?

> Due date: Date
> Doc: not used
> Components: {Unknown, 
>              Build tools,
>              Demos/Scripts,     
>              Documentation,
>              Eclipe plug-in,
>              Javadoc,
>              JDBC,
>              JMX,
>              Localization,
>              Miscellaneous,
>              Network Client,
>              Network Server,
>              Replication,
>              Services,
>              SQL,
>              Store,
>              Test,
>              Tools,
>              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}
> Doc: 
> Comment: no changes
> Fix version: {Unknown, Unreleased versions, Released versions}
> Doc:
> 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
>      (http://db.apache.org/derby/derby_mail.html).
> 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.
> Comment: 
> Original Estimate: *w *d *h *m
> Doc: Not currently used
> Derby issue & fix info: boolean check-boxes
>      High value fix
>      Known fix
>      Newcomer
>      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
>                      implemented.
>                      - 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.
It would be good to refer to the Wiki page regarding making release note:

>      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
>                           attachment.
> 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"
>      perhaps?
Yes, if we can resolve the issue of multiple releases going on at once.
>      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
>      Crash
>      Data corruption
>      Deviation from standard
>      Embedded/client difference
>      Performance
>      Regression
>      Regression test failure
>      Security
>      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
>      Performance
>      Regression: A bug that was not present in some previous publicly
>                  available release.
>      Regression test failure
>      Security
>      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)
I think "Seen in production" is useful.

View raw message