You are viewing a plain text version of this content. The canonical link for it is here.

Posted to derby-dev@db.apache.org by Kathey Marsden <km...@sbcglobal.net> on 2009/05/21 20:23:36 UTC

IRC meeting for bug review and High Value Fix list

I would like to plan a bug review meeting on #derby IRC on Monday, June
8 at 15:00 UTC (that's 8:00am PDT), (5:00pm CEST) if I figure this
correctly.

Since we have a lot of open issues, I would like to focus this meeting
on the High Value Fix Candidate list:
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10594&customfield_12310200=High+Value+Fix&resolution=-1&sorter/field=issuekey&sorter/order=DESC

The goal of the meeting will be to get this list down to a list of 40
issues that the community agrees will offer highest return on time
investment. Currently the list is at 53. Some will come off and I am
sure others will be added as part of this process.

The way the game works is *before* the meeting (by Friday June 5)
everyone goes through whatever lists they like and marks the open issues
they think belong on the list by checking the checkbox in Jira. You
may find the reports on this page useful:
http://wiki.apache.org/db-derby/DerbyJiraReports. If you added an issue
to the list, you can take it off, but you can't take off an issue
someone else marked high value, without getting their ok by posting your
request to have it removed to the Jira issue.

Come to the meeting ready to advocate for your issues. At the meeting,
we go over the high value list ,and trim it down to 40. Bumped issues
will get a comment in Jira with an explanation and of course can go back
on the list once we clear the backlog a bit.

Does anyone have any objections to the format of the meeting?
Will someone volunteer to be secretary and summarize to the list and
make the agreed upon Jira modifications?

Also please look at the Wiki page definition of High Value
http://wiki.apache.org/db-derby/HighValueFixCandidates
Questions:
Is this definition ok or could it be made clearer?
Should the list include improvements and testing build tool issues
or just bugs?
Should we include documentation? I think DERBY-4165, DERBY-4034,
and DERBY-1209 would make nice additions, but of course that eats into
our 40.

Thanks

Kathey

CANCELLED Re: IRC meeting for bug review and High Value Fix list

Posted by Kathey Marsden <km...@sbcglobal.net>.

Kathey Marsden wrote:
> I would like to plan a bug review meeting on  #derby IRC on Monday, 
> June 8  at 15:00 UTC (that's 8:00am PDT), (5:00pm CEST)  if I figure 
> this correctly.
>
Canceling this meeting due to ongoing discussion of the Jira fields and 
other discussions regarding alternative methods of  triaging the bug 
list.  We can reschedule later if needed.

Kathey

Re: IRC meeting for bug review and High Value Fix list

Posted by "Jean T. Anderson" <jt...@bristowhill.com>.

Kathey Marsden wrote:
> I would like to plan a bug review meeting on  #derby IRC on Monday, 
> June 8  at 15:00 UTC (that's 8:00am PDT), (5:00pm CEST)  if I figure 
> this correctly.
>
This shows everyone the time in their zone:

http://tinyurl.com/ppfbqz

 -jean

Re: Jira field definitions

Posted by "Dag H. Wanvik" <Da...@Sun.COM>.

Thanks for your prompt feed-back, Kathey!
Comments inlined.

Kathey Marsden <km...@sbcglobal.net> writes:

>> 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.

I agree, will reword that.

>> 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?

Good point. Unless we can come up with a way to encode this, I suggest
we keep the flag for now.I guess what we'd really need is two urgency
fields, one for the upcoming release and one for trunk.. If that
sounds unpalatable, I suggest we keep the flag for now?

>>
>>   
> It would be good to refer to the Wiki page regarding making release note:
> http://wiki.apache.org/db-derby/ReleaseNoteProcess#head-8bfe22837d50a10f61f410c927336eabc682b62f

+1, Will do.

> I think "Seen in production" is useful.

+1.

Dag

Re: Jira field definitions

Posted by Kathey Marsden <km...@sbcglobal.net>.

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:
http://wiki.apache.org/db-derby/ReleaseNoteProcess#head-8bfe22837d50a10f61f410c927336eabc682b62f

>      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.

Re: Usage of "Test" component in JIRA

Posted by Knut Anders Hatlen <Kn...@Sun.COM>.

Dag.Wanvik@Sun.COM (Dag H. Wanvik) writes:

> Dag.Wanvik@Sun.COM (Dag H. Wanvik) writes:
>
>> This left many issues without component. I have added components for
>> open issues..
>
> I have added component "Test" (as an a priori component) for those
> issues which had no other component when the "Regression Test Failure"
> was removed. But this started me thinking and I have a question on the
> recommended usage of the "Test" component. 
>
> Normally, when we fix a Derby bug, we add a new test case to the
> regression tests. This means that a patch for an issue will touch
> both, say, the "Store" component and the "Test" component.
>
> I don't think we have had a clear practice on whether to mark such
> issues with the additional "Test" component or not. Since the focus of
> the issue would be the bug or modification in Derby itself, the "Test"
> component is often not given. Do we want to tighten this up and
> recommend to use the "Test" component in addition if the test code is
> at all modified by the patch? Or would it be better to reserve the
> "Test" component usage for cases where the focus is test or test
> infrastructure?

I think I'd prefer that we only use the Test component if there's a bug
in the test code or if the main focus of the issue is to improve the
test code. Otherwise, almost all issues would have the Test component,
since most improvements and bug fixes are accompanied by a regression
test. Limiting the Test component to pure test issues would make it more
usable in queries, in my opinion.

-- 
Knut Anders

Re: Usage of "Test" component in JIRA

Posted by Rick Hillegas <Ri...@Sun.COM>.

Hi Dag,

Thanks for doing all this work. Some comments below...

Dag H. Wanvik wrote:
> Dag.Wanvik@Sun.COM (Dag H. Wanvik) writes:
>
>   
>> This left many issues without component. I have added components for
>> open issues..
>>     
>
> I have added component "Test" (as an a priori component) for those
> issues which had no other component when the "Regression Test Failure"
> was removed. But this started me thinking and I have a question on the
> recommended usage of the "Test" component. 
>
> Normally, when we fix a Derby bug, we add a new test case to the
> regression tests. This means that a patch for an issue will touch
> both, say, the "Store" component and the "Test" component.
>
> I don't think we have had a clear practice on whether to mark such
> issues with the additional "Test" component or not. Since the focus of
> the issue would be the bug or modification in Derby itself, the "Test"
> component is often not given. Do we want to tighten this up and
> recommend to use the "Test" component in addition if the test code is
> at all modified by the patch? Or would it be better to reserve the
> "Test" component usage for cases where the focus is test or test
> infrastructure?
>   
I don't have any experience with the new scheme so my advice won't be 
grounded in reality. Off the top of my head, it seems that this 
component is going to start out flagging the following issues:

1) JIRAs whose Issue Type used to be "Test"

2) JIRAs whose Component used to be "Regression Test Failure"

I suspect that these are mostly issues whose primary focus is test code, 
not product code. If we want to broaden the meaning of the new "Test" 
Component, I would want to think about the following questions:

A) Will this give rise to some new, useful JIRA queries?

B) Will this make other JIRA queries less useful or harder to write?

Thanks,
-Rick
> Thanks,
> Dag
>

Re: Usage of "Test" component in JIRA

Posted by "Dag H. Wanvik" <Da...@Sun.COM>.

Kathey Marsden <km...@sbcglobal.net> writes:

> I think I prefer the latter. In terms of a query I would think this
> would be most useful for someone with a QA focus wanting to identify
> outstanding or fixed test issues.  If we expand it to everything that
> needs a regression test, then I can't imagine a really useful query
> for it.

+1

Thanks everyone. I will use this recommendation in the new docs.

Dag

Re: Usage of "Test" component in JIRA

Posted by Kathey Marsden <km...@sbcglobal.net>.

Dag H. Wanvik wrote:
>  Do we want to tighten this up and
> recommend to use the "Test" component in addition if the test code is
> at all modified by the patch? Or would it be better to reserve the
> "Test" component usage for cases where the focus is test or test
> infrastructure?
>
>   
I think I prefer the latter. In terms of a query I would think this 
would be most useful for someone with a QA focus wanting to identify 
outstanding or fixed test issues.  If we expand it to everything that 
needs a regression test, then I can't imagine a really useful query for it.

Kathey

Usage of "Test" component in JIRA

Posted by "Dag H. Wanvik" <Da...@Sun.COM>.

Dag.Wanvik@Sun.COM (Dag H. Wanvik) writes:

> This left many issues without component. I have added components for
> open issues..

I have added component "Test" (as an a priori component) for those
issues which had no other component when the "Regression Test Failure"
was removed. But this started me thinking and I have a question on the
recommended usage of the "Test" component. 

Normally, when we fix a Derby bug, we add a new test case to the
regression tests. This means that a patch for an issue will touch
both, say, the "Store" component and the "Test" component.

I don't think we have had a clear practice on whether to mark such
issues with the additional "Test" component or not. Since the focus of
the issue would be the bug or modification in Derby itself, the "Test"
component is often not given. Do we want to tighten this up and
recommend to use the "Test" component in addition if the test code is
at all modified by the patch? Or would it be better to reserve the
"Test" component usage for cases where the focus is test or test
infrastructure?

Thanks,
Dag

Re: Jira field definitions

Posted by "Dag H. Wanvik" <Da...@Sun.COM>.

Rick Hillegas <Ri...@Sun.COM> writes:

> I see. And you can still search for Sub-task types it seems.

Yes, I did not remove sub-task.

Dag

Re: Jira field definitions

Posted by Rick Hillegas <Ri...@Sun.COM>.

Kristian Waagan wrote:
> Rick Hillegas wrote:
>> Hi Dag,
>>
>> Once again, thanks for overhauling our JIRA form. I just want to note 
>> what I think is a welcome divergence from last week's version of your 
>> proposal. I thought that your proposal called for paring back the 
>> legal values of the Issue Type field to Bug, Improvement, Task, and 
>> Sub-task. I see that you have eliminated the last value as well. So 
>> now there are only 3 values: Bug, Improvement, and Task. I think 
>> that's ok because Sub-tasks can be flagged by linking issues together.
>
> For clarity, we can still create sub-tasks. What has changed, I guess, 
> is that it can't be done from the main "Create new issue" link any more.
> For existing issues you can just click "Create sub-task" though.
I see. And you can still search for Sub-task types it seems.

Thanks,
-Rick
>
>
> Regards,

Re: Jira field definitions

Posted by Kristian Waagan <Kr...@Sun.COM>.

Rick Hillegas wrote:
> Hi Dag,
>
> Once again, thanks for overhauling our JIRA form. I just want to note 
> what I think is a welcome divergence from last week's version of your 
> proposal. I thought that your proposal called for paring back the 
> legal values of the Issue Type field to Bug, Improvement, Task, and 
> Sub-task. I see that you have eliminated the last value as well. So 
> now there are only 3 values: Bug, Improvement, and Task. I think 
> that's ok because Sub-tasks can be flagged by linking issues together.

For clarity, we can still create sub-tasks. What has changed, I guess, 
is that it can't be done from the main "Create new issue" link any more.
For existing issues you can just click "Create sub-task" though.


Regards,
-- 
Kristian
>
> Thanks,
> -Rick
>
> Dag H. Wanvik wrote:
>> Another update, folks, the next phase has been completed, Derby now
>> uses its own JIRA Issue Type Scheme, which means that the "Wish", "New
>> Feature", and "Test" issue types are gone. Old "Test" issues have been
>> converted to "Bug" or "Improvement" on a case by case basis, "Wish"
>> and "New Feature" have been moved to "Improvement".
>>
>> Of course I forgot to unclick the "Send email" check-box in one case
>> so you have been properly spammed again; sorry!
>>
>> Dag
>>   
>

Re: Jira field definitions

Posted by Rick Hillegas <Ri...@Sun.COM>.

Hi Dag,

Once again, thanks for overhauling our JIRA form. I just want to note 
what I think is a welcome divergence from last week's version of your 
proposal. I thought that your proposal called for paring back the legal 
values of the Issue Type field to Bug, Improvement, Task, and Sub-task. 
I see that you have eliminated the last value as well. So now there are 
only 3 values: Bug, Improvement, and Task. I think that's ok because 
Sub-tasks can be flagged by linking issues together.

Thanks,
-Rick

Dag H. Wanvik wrote:
> Another update, folks, the next phase has been completed, Derby now
> uses its own JIRA Issue Type Scheme, which means that the "Wish", "New
> Feature", and "Test" issue types are gone. Old "Test" issues have been
> converted to "Bug" or "Improvement" on a case by case basis, "Wish"
> and "New Feature" have been moved to "Improvement".
>
> Of course I forgot to unclick the "Send email" check-box in one case
> so you have been properly spammed again; sorry!
>
> Dag
>

Re: Jira field definitions

Posted by "Dag H. Wanvik" <Da...@Sun.COM>.

Another update, folks, the next phase has been completed, Derby now
uses its own JIRA Issue Type Scheme, which means that the "Wish", "New
Feature", and "Test" issue types are gone. Old "Test" issues have been
converted to "Bug" or "Improvement" on a case by case basis, "Wish"
and "New Feature" have been moved to "Improvement".

Of course I forgot to unclick the "Send email" check-box in one case
so you have been properly spammed again; sorry!

Dag

Re: Jira field definitions

Posted by Kristian Waagan <Kr...@Sun.COM>.

Kathey Marsden wrote:
> Dag H. Wanvik wrote:
>> You are right, I did move items to make the order alphabetical, but I
>> could make that one back on top. Would others also like that?
>>
>>   
> Someone at one time had talked about making it so you could click it 
> with the attach function. That would be ideal but perhaps that proved 
> too hard. 

I looked into this at one point, but it proved too hard to do since 
we're sharing the Jira instance with others. As far as I understood, at 
that point the only way to do this was to change the on-disk template / 
source file [1].

It may be possible to make this happen if we get everyone using it to 
agree with the change, but that sounds like a lot of work to me.
For the record, the current version of the running Jira instance is 3.13.2.

-- 
Kristian

[1] 
http://www.nabble.com/Patch-available-checkbox-on-the-attach-file-page--td15203629.html

> Otherwise, top or alphabetical is fine with me.
> Kathey
>

Re: Jira field definitions

Posted by Kathey Marsden <km...@sbcglobal.net>.

Dag H. Wanvik wrote:
> You are right, I did move items to make the order alphabetical, but I
> could make that one back on top. Would others also like that?
>
>   
Someone at one time had talked about making it so you could click it 
with the attach function. That would be ideal but perhaps that proved 
too hard.  Otherwise, top or alphabetical is fine with me. 

Kathey

Re: Jira field definitions

Posted by "Dag H. Wanvik" <Da...@Sun.COM>.

Kim Haase <Ca...@Sun.COM> writes:

> I have only one question -- in the "Issue & fix info" group, I think
> Patch Available used to be at the top of the list. I think it's the
> most commonly used of these checkboxes, so maybe it should be moved
> back up there to make it easy to find?

You are right, I did move items to make the order alphabetical, but I
could make that one back on top. Would others also like that?

Dag

Re: Jira field definitions

Posted by Kim Haase <Ca...@Sun.COM>.

Thanks very much for doing this work, Dag!

I have only one question -- in the "Issue & fix info" group, I think 
Patch Available used to be at the top of the list. I think it's the most 
commonly used of these checkboxes, so maybe it should be moved back up 
there to make it easy to find?

Kim

Dag H. Wanvik wrote:
> Update, I have now done the check-boxes rototill as per the
> memo. Please have a look and let me know if there are any anomalies.
> 
> Thanks,
> Dag

Re: Jira field definitions

Posted by "Dag H. Wanvik" <Da...@Sun.COM>.

Update, I have now done the check-boxes rototill as per the
memo. Please have a look and let me know if there are any anomalies.

Thanks,
Dag

Re: Jira field definitions

Posted by "Dag H. Wanvik" <Da...@Sun.COM>.

Hi folks,

sorry for all the noise, I had to perform some some bulk ops manually..

Current state: I have implemented moving the 4 moribund components
settings to check-boxes by setting the corresponding check-box and
deleting those four components (newcomer, performance, regression test
failure, security).

This left many issues without component. I have added components for
open issues, except for those that are security related. I will get on
to those tomorrow, and proceed next with adding the check-box
revisions.

Thanks,
Dag

Dag.Wanvik@Sun.COM (Dag H. Wanvik) writes:

> Invoking the lazy consensus procedure, i intend to go ahead with
> changes proposed in this memo on JIRA field definitions if no protests
> have been seen by 4pm Friday, June 26, PST.

Re: Jira field definitions

Posted by "Dag H. Wanvik" <Da...@Sun.COM>.

Hi all,

thanks for the quick help in resolving these questions.

Invoking the lazy consensus procedure, i intend to go ahead with
changes proposed in this memo on JIRA field definitions if no protests
have been seen by 4pm Friday, June 26, PST.

In addition to changing our custom JIRA fields to comply, I will also
bulk move still open issues of type Wish and New Feature to type
Improvement. I will also update existing Derby JIRA docs to reflect
the new usage.

Thanks,
Dag

----------------------------------------------------------------------
JIRA field proposal Version 1.1

Changes relative to proposal initial proposal:
(http://mail-archives.apache.org/mod_mbox/db-derby-dev/200906.mbox/%3Cx1oxr5xknt99.fsf_-_@sun.com%3E)

- customers -> users
- "Derby Issue & fix info" renamed to just "Issue & fix info"
- typo "Not" -> "Note"
- removed three "is this useful?" meta-questions
- updated wording on "High Value Fix" field to contrast it to
- "Urgency".

Changes relative to proposal 1.0

- removed a meta-question from "High Value Fix"

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
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 5 (trivial;
least severe) to severity 1 (most severe: blocker). Typically, this
field will not change unless more information about the bug becomes
available from investigation or from users. Its value is normally
not changed by release and scheduling decisions. Note 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 bug
triage, no bug should have the "none" urgency.

Comment: See also "High Value Fix" checkbox

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

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 ("bang for the bucks")
- 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.

In contrast to the "Urgency" field, "High value
fix" is typically *not* used to reflect
scheduling decisions for a particular release,
but can be thought of a a longer term ("trunk",
"next major release") consideration. For
example, even if a bug is not slotted to be
included in a particular update release, it can
still be useful to label it as something we want
to fix soon for a variety of reasons.

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.

http://wiki.apache.org/db-derby/ReleaseNoteProcess#head-8bfe22837d50a10f61f410c927336eabc682b62f

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 "Issue & fix info" to distinguish
from Bug Behavior Facts.
Added "Repro attached" and "Workaround attached" and "known fix".
Removed "Existing application impact".
Moved "Newcomer" here from "Bug Behavior Facts".

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 "Issue & fix info". Moved
"Newcomer" to Issue & fix info.
Added "seen in production".

Re: Jira field definitions

Posted by "Dag H. Wanvik" <Da...@Sun.COM>.

Kathey Marsden <km...@sbcglobal.net> writes:

> I think it is fine too except we should remove the question:
> Can we merge the semantics of "High value fix" into "Urgency"
>     perhaps? ""

+1. Thanks, Rick and Kathey.

Re: Jira field definitions

Posted by Kathey Marsden <km...@sbcglobal.net>.

Rick Hillegas wrote:
> Thanks for posting this new version, Dag. Looks good to me.
>
> Regards,
> -Rick
>
I think it is fine too except we should remove the question:
Can we merge the semantics of "High value fix" into "Urgency"
     perhaps? ""
> Dag H. Wanvik wrote:
>> Hi,
>>
>> posting a new version incorporating comments I have received so far,
>> thanks everyone! If not further comments arise, I will put this
>> version up for a vote in a day or two. Process issues are decided by
>> simple majority and the vote should run for at least 72 hours
>> (http://www.apache.org/foundation/voting.html).
>>
>> I do think Kathey is right that we may still need to tweak the
>> definitions a bit as we go along in the triaging process, but perhaps
>> it's still good to vote on this set of changes as a baseline. Smaller
>> changes later could be handled by lazy consensus.
>>
>> Dag
>> ----------------------------------------------------------------------
>> JIRA field proposal Version 1.0
>>
>> Changes relative to proposal initial proposal:   
>> (http://mail-archives.apache.org/mod_mbox/db-derby-dev/200906.mbox/%3Cx1oxr5xknt99.fsf_-_@sun.com%3E) 
>>
>>
>>   - Changed severity numbering in "Priority" field (1 is most severe -
>>     Kathey)
>>   - rewording: customers -> users (Kathey)
>>   - "Derby Issue & fix info" renamed to just "Issue & fix info"
>>   - typo "Not" -> "Note" (Rick)
>>   - removed three "is this useful?" meta-questions
>>   - updated wording on "High Value Fix" field to contrast it to 
>> "Urgency".
>>
>>
>> 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
>> 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 5 (trivial;
>> least severe) to severity 1 (most severe: blocker). Typically, this
>> field will not change unless more information about the bug becomes
>> available from investigation or from users. Its value is normally
>> not changed by release and scheduling decisions. Note 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 bug
>> triage, no bug should have the "none" urgency.
>>
>>
>> Comment: See also "High Value Fix" checkbox
>>
>>
>> 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
>>
>>
>> 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 ("bang for the 
>> bucks")
>>                      - 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.
>>                                           In contrast to the 
>> "Urgency" field, "High value
>>                      fix" is typically *not* used to reflect
>>                      scheduling decisions for a particular release,
>>                      but can be thought of a a longer term ("trunk",
>>                      "next major release")  consideration. For
>>                      example, even if a bug is not slotted to be
>>                      included in a particular update release, it can
>>                      still be useful to label it as something we want
>>                      to fix soon.
>>
>>
>>      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.
>>
>>                           
>> http://wiki.apache.org/db-derby/ReleaseNoteProcess#head-8bfe22837d50a10f61f410c927336eabc682b62f 
>>
>>
>>      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 "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?
>>      Moved "Newcomer" here from "Bug Behavior Facts".
>>
>> 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 "Issue & fix info". Moved
>>          "Newcomer" to Issue & fix info.
>>          Added "seen in production".
>>   
>
>

Re: Jira field definitions

Posted by Rick Hillegas <Ri...@Sun.COM>.

Thanks for posting this new version, Dag. Looks good to me.

Regards,
-Rick

Dag H. Wanvik wrote:
> Hi,
>
> posting a new version incorporating comments I have received so far,
> thanks everyone! If not further comments arise, I will put this
> version up for a vote in a day or two. Process issues are decided by
> simple majority and the vote should run for at least 72 hours
> (http://www.apache.org/foundation/voting.html).
>
> I do think Kathey is right that we may still need to tweak the
> definitions a bit as we go along in the triaging process, but perhaps
> it's still good to vote on this set of changes as a baseline. Smaller
> changes later could be handled by lazy consensus.
>
> Dag
> ----------------------------------------------------------------------
> JIRA field proposal Version 1.0
>
> Changes relative to proposal initial proposal: 
>   (http://mail-archives.apache.org/mod_mbox/db-derby-dev/200906.mbox/%3Cx1oxr5xknt99.fsf_-_@sun.com%3E)
>
>   - Changed severity numbering in "Priority" field (1 is most severe -
>     Kathey)
>   - rewording: customers -> users (Kathey)
>   - "Derby Issue & fix info" renamed to just "Issue & fix info"
>   - typo "Not" -> "Note" (Rick)
>   - removed three "is this useful?" meta-questions
>   - updated wording on "High Value Fix" field to contrast it to "Urgency".
>
>
> 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
> 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 5 (trivial;
> least severe) to severity 1 (most severe: blocker). Typically, this
> field will not change unless more information about the bug becomes
> available from investigation or from users. Its value is normally
> not changed by release and scheduling decisions. Note 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 bug
> triage, no bug should have the "none" urgency.
>
>
> Comment: See also "High Value Fix" checkbox
>
>
> 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
>
>
> 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 ("bang for the bucks")
>                      - 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.
>                      
>                      In contrast to the "Urgency" field, "High value
>                      fix" is typically *not* used to reflect
>                      scheduling decisions for a particular release,
>                      but can be thought of a a longer term ("trunk",
>                      "next major release")  consideration. For
>                      example, even if a bug is not slotted to be
>                      included in a particular update release, it can
>                      still be useful to label it as something we want
>                      to fix soon.
>
>
>      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.
>
>                           http://wiki.apache.org/db-derby/ReleaseNoteProcess#head-8bfe22837d50a10f61f410c927336eabc682b62f
>
>      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 "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?
>      Moved "Newcomer" here from "Bug Behavior Facts".
>
> 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 "Issue & fix info". Moved
>          "Newcomer" to Issue & fix info.
>          Added "seen in production".
>

Re: Jira field definitions

Posted by "Dag H. Wanvik" <Da...@Sun.COM>.

Rick Hillegas <Ri...@Sun.COM> writes:

> Alternatively, you could propose the first slug of changes under lazy
> consensus. You would say "Here's my proposal, which I intend to
> implement in 3 days if there are no objections." See
> http://www.apache.org/foundation/voting.html and
> http://www.apache.org/foundation/voting.html#LazyConsensus I think we
> just want to ensure that we give decent notice to people who may have
> objections.

Right, more expedient I think, given the upcoming release date and the
need for triaging. I'll await any comments to the current draft, and
give a lazy consensus note on what I have in a day or two.

Meanwhile, there are lots of bugs that need fixing :)

Dag

Re: Jira field definitions

Posted by Rick Hillegas <Ri...@Sun.COM>.

Dag H. Wanvik wrote:
> Dag.Wanvik@Sun.COM (Dag H. Wanvik) writes:
>
>   
>> Hi,
>>
>> posting a new version incorporating comments I have received so far,
>> thanks everyone! If not further comments arise, I will put this
>> version up for a vote in a day or two. Process issues are decided by
>> simple majority and the vote should run for at least 72 hours
>> (http://www.apache.org/foundation/voting.html).
>>     
>
> Not so, Knut reminded me that DB has a week minimum voting period:
>
> http://db.apache.org/management.html
>
> "Voting
>
> The call for a vote on issues not detailed here may specify
> requirements for passage. The minimum and default requirement for a
> passing vote is simple majority of PMC members casting ballots. The
> default voting period is 10 days and the minimum is 7 days unless the
> success or failure is arithmetically known."
>
> Dag
>   
Alternatively, you could propose the first slug of changes under lazy 
consensus. You would say "Here's my proposal, which I intend to 
implement in 3 days if there are no objections." See 
http://www.apache.org/foundation/voting.html and 
http://www.apache.org/foundation/voting.html#LazyConsensus I think we 
just want to ensure that we give decent notice to people who may have 
objections.

Thanks,
-Rick

Re: Jira field definitions

Posted by "Dag H. Wanvik" <Da...@Sun.COM>.

Dag.Wanvik@Sun.COM (Dag H. Wanvik) writes:

> Hi,
>
> posting a new version incorporating comments I have received so far,
> thanks everyone! If not further comments arise, I will put this
> version up for a vote in a day or two. Process issues are decided by
> simple majority and the vote should run for at least 72 hours
> (http://www.apache.org/foundation/voting.html).

Not so, Knut reminded me that DB has a week minimum voting period:

http://db.apache.org/management.html

"Voting

The call for a vote on issues not detailed here may specify
requirements for passage. The minimum and default requirement for a
passing vote is simple majority of PMC members casting ballots. The
default voting period is 10 days and the minimum is 7 days unless the
success or failure is arithmetically known."

Dag

Re: Jira field definitions

Posted by "Dag H. Wanvik" <Da...@Sun.COM>.

Hi,

posting a new version incorporating comments I have received so far,
thanks everyone! If not further comments arise, I will put this
version up for a vote in a day or two. Process issues are decided by
simple majority and the vote should run for at least 72 hours
(http://www.apache.org/foundation/voting.html).

I do think Kathey is right that we may still need to tweak the
definitions a bit as we go along in the triaging process, but perhaps
it's still good to vote on this set of changes as a baseline. Smaller
changes later could be handled by lazy consensus.

Dag
----------------------------------------------------------------------
JIRA field proposal Version 1.0

Changes relative to proposal initial proposal:
(http://mail-archives.apache.org/mod_mbox/db-derby-dev/200906.mbox/%3Cx1oxr5xknt99.fsf_-_@sun.com%3E)

- Changed severity numbering in "Priority" field (1 is most severe -
Kathey)
- rewording: customers -> users (Kathey)
- "Derby Issue & fix info" renamed to just "Issue & fix info"
- typo "Not" -> "Note" (Rick)
- removed three "is this useful?" meta-questions
- updated wording on "High Value Fix" field to contrast it to "Urgency".

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

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

Comment: See also "High Value Fix" checkbox

Due date: Date
Doc: not used

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

Fix version: {Unknown, Unreleased versions, Released versions}
Doc:
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:

Comment:

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

http://wiki.apache.org/db-derby/ReleaseNoteProcess#head-8bfe22837d50a10f61f410c927336eabc682b62f

Doc: The Bug Behavior Facts contain additional yes/no check-box
characterization of the issue.

Comment: Renamed to "Bug behavior facts:" from Categories.
Moved "regression" here from "Issue & fix info". Moved
"Newcomer" to Issue & fix info.
Added "seen in production".

Re: Jira field definitions

Posted by "Dag H. Wanvik" <Da...@Sun.COM>.

Rick Hillegas <Ri...@Sun.COM> writes:

> 2) To remove some values for the Issue Type field (I think this is the
> only instance where you are proposing to remove information). I
> believe you have said that you will bulk re-assign all "New Feature"
> values to "Improvement". 

Yes.

> What are you proposing to do with the "Wish" and "Test" issues?

I don't propose to change any closed issued. Does anyone think that
should be done as well? 

The currently open Wish issues are:
                                                                               
Wish DERBY-3910 debug artifacts should be available in maven repositories The "directory" component of the JDBC connection    
Wish DERBY-3281 string should permit leading slashes on the windows platform   
Wish DERBY-2039 cant get CHAR from Character          
Wish DERBY-601 Greater support is needed for the use the java.util.calendar class 
Wish DERBY-262  Use Java 1.5 NIO for improved performance 
Wish DERBY-152  Implement COMMIT SQL Statement      
Wish DERBY-103  Global Oracle/Axion style        

I intend to map all the above to "Improvement".

The test issues I will map to type "Bug" or "Improvement" as the case may be,
and also use the Test component, if not already used.

>
> 3) To update the wiki page which explains how to fill-in a JIRA.

Yes, I intend to do that once we have an agreement.

Dag

Re: Jira field definitions

Posted by Kathey Marsden <km...@sbcglobal.net>.

Rick Hillegas wrote:
> You're the next release manager. If you want to publish some 
> easy-to-evaluate rules for filling-in this field, I'm happy to 
> sanity-check this field too when I triage my lump of JIRAs. Something, 
> for instance, which mapped check boxes to Urgency values, like this:
>
> Data Corruption => Blocker
> Crash = > Blocker
> Wrong query result + Seen in production + has no workaround => Blocker
> Performance + Seen in production + has no workaround => Urgent
> Security + Seen in production + has no workaround => Urgent
> Everything else => Normal
>

Well wouldn't it be nice if our standards were that high #:)    Truth is 
we have let many of the things that would fall under  Blocker with these 
rules go release after release.  Ultimately things that really should be 
fixed will get pushed off the list yet again, but I do suppose we could 
come up with some set of rules for a bulk update and use that as 
starting point for compromise.    I will think about it.

Kathey

Re: Jira field definitions

Posted by Rick Hillegas <Ri...@Sun.COM>.

Kathey Marsden wrote:
> Rick Hillegas wrote:
>>>
>> This is what I intend to do during the triage:
>>
>> 1) Sanity check the Issue Type field.
>>
>> 2) Sanity check and mark all applicable check boxes.
>>
>> Those fields plus the user votes will give me the information I need 
>> to guide my bug fixing.
> I guess that would bring me back to Urgency then.  Dag said:
>
> "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.
>
> "
>
>
> It seems reasonable that the release manager would be able to use this 
> field to mark issues as Blocker or maybe even Urgent, but it seems it 
> would be a bit cumbersome to rank all of the issues with his/her 
> personal opinion and as you say individuals will use whatever method 
> they like to prioritize their bug fixing for non-blocker issues.
You're the next release manager. If you want to publish some 
easy-to-evaluate rules for filling-in this field, I'm happy to 
sanity-check this field too when I triage my lump of JIRAs. Something, 
for instance, which mapped check boxes to Urgency values, like this:

Data Corruption => Blocker
Crash = > Blocker
Wrong query result + Seen in production + has no workaround => Blocker
Performance + Seen in production + has no workaround => Urgent
Security + Seen in production + has no workaround => Urgent
Everything else => Normal

An enterprising soul might even be able to write a script which updates 
the Urgency field given a set of rules like those above.

Thanks,
-Rick

>
>
> Kathey
>

Re: Jira field definitions

Posted by Kathey Marsden <km...@sbcglobal.net>.

Rick Hillegas wrote:
>>
> This is what I intend to do during the triage:
>
> 1) Sanity check the Issue Type field.
>
> 2) Sanity check and mark all applicable check boxes.
>
> Those fields plus the user votes will give me the information I need 
> to guide my bug fixing.
I guess that would bring me back to Urgency then.  Dag said:

"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.

"

It seems reasonable that the release manager would be able to use this 
field to mark issues as Blocker or maybe even Urgent, but it seems it 
would be a bit cumbersome to rank all of the issues with his/her 
personal opinion and as you say individuals will use whatever method 
they like to prioritize their bug fixing for non-blocker issues.

Kathey

Re: Jira field definitions

Posted by Rick Hillegas <Ri...@Sun.COM>.

Kathey Marsden wrote:
> Rick Hillegas wrote:
>>
>> Once you have specified what to do with the lingering questions in 
>> (2), I think that you will have a well-defined proposal for a 
>> community vote. I regard this as a procedural issue so I think that 
>> the rules of engagement would be majority vote by PMC members: 
>> http://www.apache.org/foundation/voting.html
>>
>> This looks like a good step in the right direction. Once the vote 
>> closes and the form is changed, I look forward to helping triage the 
>> open bugs.
>>
> I don't know that a vote is really necessary as  I am sure the process 
> will continue to evolve as we determine how we will conduct the triage 
> and start using the updated procedures.   If we do need a vote, we 
> probably should discuss how we want to conduct the triage first as it 
> might impact the fields we need.
>
> Kathey
>
>
This is what I intend to do during the triage:

1) Sanity check the Issue Type field.

2) Sanity check and mark all applicable check boxes.

Those fields plus the user votes will give me the information I need to 
guide my bug fixing.

Thanks,
-Rick

Re: Jira field definitions

Posted by Kathey Marsden <km...@sbcglobal.net>.

Rick Hillegas wrote:
>
> Once you have specified what to do with the lingering questions in 
> (2), I think that you will have a well-defined proposal for a 
> community vote. I regard this as a procedural issue so I think that 
> the rules of engagement would be majority vote by PMC members: 
> http://www.apache.org/foundation/voting.html
>
> This looks like a good step in the right direction. Once the vote 
> closes and the form is changed, I look forward to helping triage the 
> open bugs.
>
I don't know that a vote is really necessary as  I am sure the process 
will continue to evolve as we determine how we will conduct the triage 
and start using the updated procedures.   If we do need a vote, we 
probably should discuss how we want to conduct the triage first as it 
might impact the fields we need.

Kathey

Re: Jira field definitions

Posted by Rick Hillegas <Ri...@Sun.COM>.

Hi Dag,

Thanks for pulling this together. +1 to the changes which Kathey 
suggested. I believe you are recommending the following:

1) To reword some fields on our JIRA form and to move some checkboxes 
around. I think these changes are well defined.

2) To remove some values for the Issue Type field (I think this is the 
only instance where you are proposing to remove information). I believe 
you have said that you will bulk re-assign all "New Feature" values to 
"Improvement". What are you proposing to do with the "Wish" and "Test" 
issues?

3) To update the wiki page which explains how to fill-in a JIRA.

Once you have specified what to do with the lingering questions in (2), 
I think that you will have a well-defined proposal for a community vote. 
I regard this as a procedural issue so I think that the rules of 
engagement would be majority vote by PMC members: 
http://www.apache.org/foundation/voting.html

This looks like a good step in the right direction. Once the vote closes 
and the form is changed, I look forward to helping triage the open bugs.

One comment below...

Thanks,
-Rick

Dag H. Wanvik wrote:
> ...
> 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)
>   
I think you mean to say "Note that users..."

Re: Jira field definitions

Posted by "Dag H. Wanvik" <Da...@Sun.COM>.

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
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 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). 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,
             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.

     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?
     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)

Re: Jirs field definitions

Posted by "Dag H. Wanvik" <Da...@Sun.COM>.

Thanks for your comments, Rick! My replies inlined.

Rick Hillegas <Ri...@Sun.COM> writes:
> I think this is fuzzy at the edges. Above you listed some consumers
> and uses of JIRA. Would any of those consumers or users be frustrated
> if we removed NewFeature and just offered the Improvement choice?

I would not think so. I, for one, would feel little if any pain by
merging these two. Other opinions?

> To my mind, the example you give could be classified as either Task or
> Improvement. To me, a good example of a Task would be one of the
> placeholder JIRAs which track the work done by a release
> manager. However, I don't think we'd lose any important information if
> we eliminated the Task issue type.

Again, I would not miss it, I think, although i don't think this isseu
type is misused much, so I am not sure it's a problem.

> ..Issue type "Test"..
> I think this is another confusing, redundant synonym for
> Improvement. Whack it!

I would love to. +1

> o Hassle. This is the issue's importance to the person who bothered to
> log it. I think we do a lousy job of tracking Hassle. In fact, we
> actively clobber it.

> 1) Priority = Hassle

What field would you suggest for capturing this? If we user the
Priority field, we can't use this field for other things. Since we
don't have special fields for tracking user's conception of bugs, I
would argue that we should try to adjust "Priority" (or "severity" as
I prefer), to some objective norm, but explain why we change its value
if we do.
>
> o Recoverability. This is some generic ranking of the issue's
> type. For instance DataCorruption > Crash > WrongResult > Abort >
> HardToUse > Ugly. We could track Recoverability better given a little
> concentration.

For me this, would be covered by the "priority" cum severity field,
augmented by the flags ("crash", "data corruption" etc).

>
> o Votes. This attempts to capture how much users in general care about
> the issue. The accuracy of this fact is dubious right now because
> users don't vote much.

Again, I think this should be the main tool for measuring how strongly
user's feel about issues. We should encorage its use more.

>
> o Releasability. This expresses how important the issue is to the
> release manager. I'm not sure the release managers handle this
> consistently, but, at the end of the day, this ranking is communicated
> to the dev list.

> 2) Urgency = Releasability

I agree this can be covered by the "Urgency" field well! +1

>
> Extra credit if we could actually rename Priority and Urgency. As long
> as they keep their original names, they will be mis-used. It doesn't
> matter if we write a clear, slim primer on how to operate
> JIRA. Self-revealing, intuitive controls always trump RTFM.

I agree this would be good, but is it possible (with the Jira being
shared among Apache projects)?

> Do we really need this much granularity? What if we pared this back to
> Blocker, Major, and Trivial?

Maybe not, but I don't see this as a major problem.

> If Urgency is basically Releasibility, then does this field need any
> values other than Blocker and Non-blocker?

Hmm. I think 3 values would be preferable, but I don't have a strong
feeling for this. Others?

Dag

Re: Jirs field definitions

Posted by "Dag H. Wanvik" <Da...@Sun.COM>.

Thanks for looking at this, Myrna!

Myrna van Lunteren <m....@gmail.com> writes:

> I'm also wondering if we should add a flag indicating that (perceived)
> incorrect behavior is happening in a production application.

Doesn't the present "Wrong query result", "Data corruption", "Crash"
and cover this need? How is this flag different? Of course, strictly,
"query" doesn't cover a wrong update, insert etc, but. Would it help
if this wording was generalized a bit? 

Another thing is what Rick mentioned in his post, how we track users'
view of things. IF we consider the JIRA a database for developers,
ideally, we would leave users' impressions alone, but we have a need
to capture our own understanding of issues as well. In the past, I
have worked with separate bug tracking databases for external,
customer facing issues, and internal developer facing bug
databases. In Derby JIRA, we have only one, so it is a compromise. I
think that my present view is that we should have Jira reflect our
best understanding. To the extents users see things differently, we
should rely on the voting system. But, as I suggested, if we change
user's appraisals, say of priority, we should explain why.

I think I agree with Rick that "Priority" should somehow reflect
"hassle" (or "severity as I like to think of it as), in contrast to
Urgency. But I am not sure we can change the possible values and/or
wording of the generic Jira fields? (e.g. Priority) Does anyone know?

> How about changing the 'Existing application impact' flag to 'fix
> impacts existing application' and adding 'problem encountered in
> production application'?

+1

Dag

Re: Jirs field definitions [was: Re: Triaging bugs, was: IRC meeting for bug review and High Value Fix list]

Posted by Myrna van Lunteren <m....@gmail.com>.

I'm also wondering if we should add a flag indicating that (perceived)
incorrect behavior is happening in a production application.
In the past, our flag 'Existing application impact' - which we agreed
means: 'the solution may have impact on existing applications' has
been (mis)used for this purpose, which suggests there is a need for a
flag of this nature in the user community.

How about changing the 'Existing application impact' flag to 'fix
impacts existing application' and adding 'problem encountered in
production application'?

Myrna

Re: Jirs field definitions [was: Re: Triaging bugs, was: IRC meeting for bug review and High Value Fix list]

Posted by Rick Hillegas <Ri...@Sun.COM>.

Thanks for this analysis, Dag. In general, I think we should strive to 
simplify our JIRA form. We are going in the right direction if we remove 
ambiguous fields or collapse them together. We are going in the wrong 
direction if we identify an ambiguity but don't resolve it. We are 
probably going in the wrong direction if we add more fields without 
removing others.

Some comments inline...

Dag H. Wanvik wrote:
> Hi,
>
> I have started working on the definitions. Instead of making en entire
> document, I'll hand out my proposed definitions (culled from other
> source or invented by me) a little bit at a time, for digestability.
> I'll collect all when we are through and put them on the Wiki.
>
> OK, first installment:
>
> -----------------------------------------------------------------
> * Guidelines for triaging Derby JIRA issues
>
> To keep the JIRA database as useful as possible, we want the
> different fields in a JIRA issue to be used as consistently as
> possible. This enables quicker identification of issues with
> certain characteristics of interest, e.g.
>
> - for a release manager to check that all show stopper bugs have
>    been addressed before a release
>
> - for developers, preparing short lists of bugs to look at fixing
>
> - se we can prune the database of old bugs that are not reproducible
>
> - so we can make different kinds of statistics to measure trends
>
> Practice over time has shown that Derby has many fields, but
> sometimes it can be hard to be sure what value to give to a
> certain field due to several reasons:
>
> - lack of immediate information: some kids of information require
>   further analysis of an issue to be able to determine its value,
>   e.g. if a bug is a code line regression or not
>
> - not obvious fields: how should I use the priority "blocker" vs
>   the urgency "blocker" value? What constitutes a crash?
>
> - JIRA provides several ways to achieve the "same thing",
>   e.g. sub-tasks vs. "is-part-of" links.
>
> Furthermore, values can be inconsistent due to users filing
> issues without necessarily reading the instructions (well), and
> even if they do, instructions are not up to date.
>
> Generally, the JIRA database is a tool for developers, so we should
> not shirk from editing user's setting of priority, urgency. If we do
> change the user's setting, we should explain in a comment why, though.
>
> This is an attempt at clarifying meanings of fields, and also to
> provide hints for filling them out. The guidelines are intended for
> committers and developers to help keep usage in line.
>
> * Title: 
>
>   - 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.
>
>     Sometimes, when working on a bug, the underlying problem turns out
>     to be different then symptom indicated in the title. In such
>     cases, keep the symptom description (but it's good to make it
>     clearer!) since this will decrease duplicates later.
>     
>     Use of keywords in the title is good, to the extent they do not
>     duplicate component information. 
>
> * Issue type
>
>   - "Bug" is pretty obvious. 
>
>   - Use "Improvement" for improving an *existing feature*, and "New
>     Feature" when it is a new user functionality. Example: allowing an
>     alternative keyword in the syntax is an improvement, not a new
>     feature. Replication is a new feature, but the limit can be hard
>     to fix sometimes, granted.
>   
I think this is fuzzy at the edges. Above you listed some consumers and 
uses of JIRA. Would any of those consumers or users be frustrated if we 
removed NewFeature and just offered the Improvement choice?
>   - "Task" (in contrast to sub-task) is for stuff that is not a bug,
>     for example code cleanups that do not result in changes in
>     behavior.
>   
To my mind, the example you give could be classified as either Task or 
Improvement. To me, a good example of a Task would be one of the 
placeholder JIRAs which track the work done by a release manager. 
However, I don't think we'd lose any important information if we 
eliminated the Task issue type.
>   - "Test" is a bit awkward, since but we also have a *component*
>     called "Test" (the component "regression test failure" will go
>     away, being replaced by the corresponding flag).
>
>     The wording in [1] is: 
>
>       "An entry regarding a test (unit, integration, system, stress
>        etc.) including requests for new tests."
>
>     The "regarding" wording above seems to cover all issues,
>     including bugs and improvements. *But*, more issue types than
>     "Test" are used by the "Test" component issues, though. Usage is
>     mixed here.
>
>     QUESTION 1: Is the issue type "Test" redundant since we have a
>     component called "Test"? 
>
>     QUESTION 2 (if answer to Q1 is "no"): should any test component
>     issue *not* use issue type test, and if so, when? For "Bug"?
>     For "improvement"? For "new issue"? The first two of these are
>     common, the last is used only in three instances.
>   
I think that Test is a Component, not an issue type. I think we should 
remove this issue type.
>     
>   - "Wish": is for user wishes, I think. Should mostly be reclassified
>     as issue type "new feature" or "improvement" if we agree it's a
>     reasonable wish. 
>   
I think this is another confusing, redundant synonym for Improvement. 
Whack it!
> * Priority
>   
I think that just about everybody in the community has been confused by 
the difference between Priority and Urgency. And not just our community. 
These fields confuse other JIRA users: http://longman.deadsquid.com/?p=249

I think that Priority and Urgency are just two of the ways that people 
try to express an issue's importance. I would like to move away from 
subjective measures of importance. I think that the following notions of 
importance are well-defined and can be regarded as facts:

o Hassle. This is the issue's importance to the person who bothered to 
log it. I think we do a lousy job of tracking Hassle. In fact, we 
actively clobber it.

o Recoverability. This is some generic ranking of the issue's type. For 
instance DataCorruption > Crash > WrongResult > Abort > HardToUse > 
Ugly. We could track Recoverability better given a little concentration.

o Votes. This attempts to capture how much users in general care about 
the issue. The accuracy of this fact is dubious right now because users 
don't vote much.

o Releasability. This expresses how important the issue is to the 
release manager. I'm not sure the release managers handle this 
consistently, but, at the end of the day, this ranking is communicated 
to the dev list.

All of these facts determine whether an itch is worth scratching. A 
moderate Hassle to your platinum customer may get fixed faster than a 
DataCorruption which only affects someone who gives the community nothing.

I would be happy with something like the following:

1) Priority = Hassle

2) Urgency = Releasability

Extra credit if we could actually rename Priority and Urgency. As long 
as they keep their original names, they will be mis-used. It doesn't 
matter if we write a clear, slim primer on how to operate JIRA. 
Self-revealing, intuitive controls always trump RTFM.


> Listed in [1], we have (quote):
>
>    - Blocker: Show-stopper! Blocks development and/or test work. No
>      work-around possible.  Needs to be worked on right away.
>
>    - Critical: Severe issue that potentially has a work-around but may
>      not be acceptable under all circumstances. Includes issues such
>      as system crashes, loss of data or severe memory leaks. New
>      features & improvements in this category are required urgently
>      but not ASAP.
>
>    - Major: Issue has a work-around but there is a major loss of
>      functionality. For new feature/improvements, this needs to be
>      implemented soon (but not urgently)
>
>    - Minor: Some loss of functionality. Work-around exists. For new
>      feature/improvements, there is no urgency with the implementation
>      of this request.
>
>    - Trivial: Lowest priority. No loss of functionality. No hurry to
>      fix/code this. Mostly a cosmetic issue like misspelled words or
>      misaligned text
>   
Do we really need this much granularity? What if we pared this back to 
Blocker, Major, and Trivial?
> * Urgency
>
> Nothing in [1]. My suggestions below.
>
>    - Blocker: We won't make a release if this one isn't fixed
>    - Urgent: Should preferably be fixed before a release is made
>    - Normal: 
>    - Low: No need to hurry about this one
>
> Note that "Blocker" is also a priority. So how to use {Priority X
> Urgency} ? It is not obvious how priority differs from urgency.
>
> A tentative definition is "Priority" is more akin to severity, that is
> its related to the product code independently of popularity and
> release plans etc, whereas "Urgency" is used as a scheduling tool, and
> the urgency of a bug can be changed over time. These two fields are
> not completely independent, I think. Please help flesh put instruction
> for how to use these two!
>   
If Urgency is basically Releasibility, then does this field need any 
values other than Blocker and Non-blocker?

Thanks,
-Rick
> Should the Priority definitions be revised now that we have urgency?
> Note that the definition for priority "major" uses the word
> "urgently".. ;-)
>
>
>
> [1] The business of Filing Apache Derby Issues in Jira
>     http://db.apache.org/derby/binaries/FilingDerbyIssuesInJira.pdf
>
> Dag
>

Jirs field definitions [was: Re: Triaging bugs, was: IRC meeting for bug review and High Value Fix list]

Posted by "Dag H. Wanvik" <Da...@Sun.COM>.

Hi,

I have started working on the definitions. Instead of making en entire
document, I'll hand out my proposed definitions (culled from other
source or invented by me) a little bit at a time, for digestability.
I'll collect all when we are through and put them on the Wiki.

OK, first installment:

-----------------------------------------------------------------
* Guidelines for triaging Derby JIRA issues

To keep the JIRA database as useful as possible, we want the
different fields in a JIRA issue to be used as consistently as
possible. This enables quicker identification of issues with
certain characteristics of interest, e.g.

- for a release manager to check that all show stopper bugs have
   been addressed before a release

- for developers, preparing short lists of bugs to look at fixing

- se we can prune the database of old bugs that are not reproducible

- so we can make different kinds of statistics to measure trends

Practice over time has shown that Derby has many fields, but
sometimes it can be hard to be sure what value to give to a
certain field due to several reasons:

- lack of immediate information: some kids of information require
  further analysis of an issue to be able to determine its value,
  e.g. if a bug is a code line regression or not

- not obvious fields: how should I use the priority "blocker" vs
  the urgency "blocker" value? What constitutes a crash?

- JIRA provides several ways to achieve the "same thing",
  e.g. sub-tasks vs. "is-part-of" links.

Furthermore, values can be inconsistent due to users filing
issues without necessarily reading the instructions (well), and
even if they do, instructions are not up to date.

Generally, the JIRA database is a tool for developers, so we should
not shirk from editing user's setting of priority, urgency. If we do
change the user's setting, we should explain in a comment why, though.

This is an attempt at clarifying meanings of fields, and also to
provide hints for filling them out. The guidelines are intended for
committers and developers to help keep usage in line.

* Title: 

  - 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.

    Sometimes, when working on a bug, the underlying problem turns out
    to be different then symptom indicated in the title. In such
    cases, keep the symptom description (but it's good to make it
    clearer!) since this will decrease duplicates later.
    
    Use of keywords in the title is good, to the extent they do not
    duplicate component information. 

* Issue type

  - "Bug" is pretty obvious. 

  - Use "Improvement" for improving an *existing feature*, and "New
    Feature" when it is a new user functionality. Example: allowing an
    alternative keyword in the syntax is an improvement, not a new
    feature. Replication is a new feature, but the limit can be hard
    to fix sometimes, granted.

  - "Task" (in contrast to sub-task) is for stuff that is not a bug,
    for example code cleanups that do not result in changes in
    behavior.

  - "Test" is a bit awkward, since but we also have a *component*
    called "Test" (the component "regression test failure" will go
    away, being replaced by the corresponding flag).

    The wording in [1] is: 

      "An entry regarding a test (unit, integration, system, stress
       etc.) including requests for new tests."

    The "regarding" wording above seems to cover all issues,
    including bugs and improvements. *But*, more issue types than
    "Test" are used by the "Test" component issues, though. Usage is
    mixed here.

    QUESTION 1: Is the issue type "Test" redundant since we have a
    component called "Test"? 

    QUESTION 2 (if answer to Q1 is "no"): should any test component
    issue *not* use issue type test, and if so, when? For "Bug"?
    For "improvement"? For "new issue"? The first two of these are
    common, the last is used only in three instances.
    
  - "Wish": is for user wishes, I think. Should mostly be reclassified
    as issue type "new feature" or "improvement" if we agree it's a
    reasonable wish. 

* Priority

Listed in [1], we have (quote):

   - Blocker: Show-stopper! Blocks development and/or test work. No
     work-around possible.  Needs to be worked on right away.

   - Critical: Severe issue that potentially has a work-around but may
     not be acceptable under all circumstances. Includes issues such
     as system crashes, loss of data or severe memory leaks. New
     features & improvements in this category are required urgently
     but not ASAP.

   - Major: Issue has a work-around but there is a major loss of
     functionality. For new feature/improvements, this needs to be
     implemented soon (but not urgently)

   - Minor: Some loss of functionality. Work-around exists. For new
     feature/improvements, there is no urgency with the implementation
     of this request.

   - Trivial: Lowest priority. No loss of functionality. No hurry to
     fix/code this. Mostly a cosmetic issue like misspelled words or
     misaligned text

* Urgency

Nothing in [1]. My suggestions below.

   - Blocker: We won't make a release if this one isn't fixed
   - Urgent: Should preferably be fixed before a release is made
   - Normal: 
   - Low: No need to hurry about this one

Note that "Blocker" is also a priority. So how to use {Priority X
Urgency} ? It is not obvious how priority differs from urgency.

A tentative definition is "Priority" is more akin to severity, that is
its related to the product code independently of popularity and
release plans etc, whereas "Urgency" is used as a scheduling tool, and
the urgency of a bug can be changed over time. These two fields are
not completely independent, I think. Please help flesh put instruction
for how to use these two!

Should the Priority definitions be revised now that we have urgency?
Note that the definition for priority "major" uses the word
"urgently".. ;-)



[1] The business of Filing Apache Derby Issues in Jira
    http://db.apache.org/derby/binaries/FilingDerbyIssuesInJira.pdf

Dag

Re: Triaging bugs, was: IRC meeting for bug review and High Value Fix list

Posted by Kathey Marsden <km...@sbcglobal.net>.

Rick Hillegas wrote:
> It might be worthwhile to spend a day or two agreeing on what these 
> fields mean:
>
Nailing down the definitions sounds good.   I asked some questions about 
High Value Fix in my previous mail.  Please continue discussion on that 
and the other fields.

>
> 5) Before calling a meeting, I would like us to triage the 355 or so 
> opn bugs. That is, I would like us to make sure that we have filled in 
> the fields listed above in item (3). This is a job which we could 
> divide up among all of the willing engineers on this list. We could 
> coordinate via email or a wiki page.
That sounds fine to me too. Just let me know how this process will work. 

Regardless of process, the important thing is to be focussed on the bug 
backlog which has gotten pretty much out of control IMHO.

Kathey

Triaging bugs, was: IRC meeting for bug review and High Value Fix list

Posted by Rick Hillegas <Ri...@Sun.COM>.

Hi Kathey,

Thanks for all of the time which you have spent cleaning up the bug 
reports recently. Let me give my $0.02:

1) I'm not sure what kind of prep can be expected before this meeting. 
In the time between now and that meeting, the Sun engineers are going to 
be busy at Java and Community One.

2) We have a lot of fields on our JIRA reports. The following three 
fields confuse me because I don't see any consistent pattern to what 
they mean. Their contents seem to be subjective. Because they are 
subjective, they don't give me much guidance in selecting bugs which 
should be fixed:

Priority
Urgency
High Value Fix

3) The following fields could have rigorous meaning and would be useful 
to me in choosing bugs. But they have limited value right now because 
people don't always remember to fill them in. It might be worthwhile to 
spend a day or two agreeing on what these fields mean:

Crash
Data corruption
Deviation from standard
Performance
Security
Wrong query result
Regression

4) In addition, I am influenced by the number of Votes which a bug has 
received.

5) Before calling a meeting, I would like us to triage the 355 or so 
open bugs. That is, I would like us to make sure that we have filled in 
the fields listed above in item (3). This is a job which we could divide 
up among all of the willing engineers on this list. We could coordinate 
via email or a wiki page. I would certainly be willing to triage a block 
of 50 bugs--I would probably be dismayed by the prospect of having to 
triage all 355 bugs by myself.

If we then ask the users to vote on the triaged bugs, I think that I 
will have all the information I need in order to focus my attention 
during the 10.5.2 bug-fixing phase. I'm not sure what I can contribute 
to this meeting if the bugs have not been triaged first. I'm also not 
sure what additional guidance this meeting can contribute once the bugs 
have been triaged and the users have voted.

Just my thoughts.

Thanks,
-Rick

Kathey Marsden wrote:
> I would like to plan a bug review meeting on  #derby IRC on Monday, 
> June 8  at 15:00 UTC (that's 8:00am PDT), (5:00pm CEST)  if I figure 
> this correctly.
>
> Since we have a lot of open issues, I would like to focus this meeting 
> on the High Value Fix Candidate list:
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10594&customfield_12310200=High+Value+Fix&resolution=-1&sorter/field=issuekey&sorter/order=DESC 
>
>
> The goal of the meeting will be to get this list down to  a list of  
> 40 issues that the community agrees will offer highest return on time 
> investment.  Currently the list is at 53. Some will come off and I am 
> sure others will be added as part of this process.
>
> The way the game works is *before* the meeting (by Friday June 5) 
> everyone goes through whatever lists they like and marks the open 
> issues they think  belong on the list by checking the checkbox in 
> Jira.  You may find the reports on this page useful: 
> http://wiki.apache.org/db-derby/DerbyJiraReports.  If you added an 
> issue to the list, you can take it off, but you can't take off an 
> issue someone else marked high value, without getting their ok by 
> posting your request to have it removed to the Jira issue.
>
> Come to the meeting ready to advocate for your issues. At the meeting, 
> we go over the high value list ,and trim it down to 40.  Bumped issues 
> will get a comment in Jira with an explanation and of course can go 
> back on the list once we clear the backlog a bit.
>
> Does anyone have any objections to the format of the meeting?
> Will someone volunteer to be secretary and summarize to the list and 
> make the agreed upon Jira modifications?
>
>
> Also please look at the Wiki page definition of High Value 
> http://wiki.apache.org/db-derby/HighValueFixCandidates
> Questions:
>    Is this definition ok or could it be made clearer?
>    Should the list include improvements and  testing  build tool 
> issues or just bugs?
>    Should we include documentation?  I think DERBY-4165, DERBY-4034, 
> and DERBY-1209 would make nice additions, but of course that eats into 
> our 40.
>
> Thanks
>
> Kathey

IRC meeting for bug review and High Value Fix list

*CANCELLED* Re: IRC meeting for bug review and High Value Fix list

Re: IRC meeting for bug review and High Value Fix list

Re: Jira field definitions

Re: Jira field definitions

Re: Usage of "Test" component in JIRA

Re: Usage of "Test" component in JIRA

Re: Usage of "Test" component in JIRA

Re: Usage of "Test" component in JIRA

Usage of "Test" component in JIRA

Re: Jira field definitions

Re: Jira field definitions

Re: Jira field definitions

Re: Jira field definitions

Re: Jira field definitions

Re: Jira field definitions

Re: Jira field definitions

Re: Jira field definitions

Re: Jira field definitions

Re: Jira field definitions

Re: Jira field definitions

Re: Jira field definitions

Re: Jira field definitions

Re: Jira field definitions

Re: Jira field definitions

Re: Jira field definitions

Re: Jira field definitions

Re: Jira field definitions

Re: Jira field definitions

Re: Jira field definitions

Re: Jira field definitions

Re: Jira field definitions

Re: Jira field definitions

Re: Jira field definitions

Re: Jira field definitions

Re: Jira field definitions

Re: Jira field definitions

Re: Jirs field definitions

Re: Jirs field definitions

Re: Jirs field definitions [was: Re: Triaging bugs, was: IRC meeting for bug review and High Value Fix list]

Re: Jirs field definitions [was: Re: Triaging bugs, was: IRC meeting for bug review and High Value Fix list]

Jirs field definitions [was: Re: Triaging bugs, was: IRC meeting for bug review and High Value Fix list]

Re: Triaging bugs, was: IRC meeting for bug review and High Value Fix list

Triaging bugs, was: IRC meeting for bug review and High Value Fix list

CANCELLED Re: IRC meeting for bug review and High Value Fix list