Daniel John Debrunner wrote:
Rick Hillegas wrote:
Hi Mike,
I agree that the "Bug Fix Candidates" heading is misleading because
the query sweeps up all open 10.3 issues, including bugs, features,
and documentation. I agree that "Bug Fix Candidates" should have a
more focussed query associated with it. Sounds like you're happy to
wire a narrower one into that slot and that sounds fine to me. I
think we should leave the original query hanging around, however. I
expect it will be useful too.
A simple solution would be to use the existing filter 'Derby open code
bugs'.
I think the practice of marking bugs as fix in a specific release as a
way to encourage folks to address them is not working. For some users
it is misleading as they might believe that the bug *is* going to be
fixed in that release and thus are surprised when it is not. This does
not reflect well on the community. Another aspect is what happens when
the release is made without the bug being fixed, currently the bug
just gets marked as some future release which seems to be even further
from reality in terms of the chances of the bug being fixed in newly
selected release.
As a concrete example the default front page for Derby on Jira says
10.2.3.0 has 62 open issues "due to be fixed", but all but a handful
are unassigned. The unassigned ones are not "due to be fixed" since
no-one is working on them. For the assigned ones I think maybe one is
actually suitable for 10.2.3.0. Thus the reality, at the moment, is
that 10.2.3.0 has one fix "due to be fixed" instead of 62.
Jira already has two mechanisms to indicate a bug is important:
Priority (which is really a severity from the descriptions of Major,
Minor etc.)
Votes: anyone can vote for a bug, if you think something should be
fixed but don't have time to fix it, vote for it.
And there's another JIRA mechanism: the Urgency field. Probably we
should consider anything that's high priority, highly urgent, or heavy
with votes.
Could we switch to the standard Jira mechanisms for indicating a bug
is important and reserve "Fix Version/s" to reflect the assignee's
expectations of where (which codelines) & when the issue will be
addressed?
I think this is a good idea. The release managers will appreciate not
having to bulk-sweep untouched issues into the next bucket.
Dan.
Thanks,
-Rick
Mike Matrigali wrote:
The 10.3 page:
http://wiki.apache.org/db-derby/DerbyTenThreeRelease?highlight=%28TenThree%29
has a heading: 10.3 Bug Fix Candidates
but the query seems to include more than just bugs. Was that the
intent, or should the query be changed. It also seems to include
documentation fixes which look like they were meant to be tracked
separately in the next section. I would find it interesting to
track intended 10.3 bug fixes vs. features separately. I can of
course create my own queries, but just wanted ask first the intent
of the existing query.
And to 10.3 bug fix planning, anyone have any ideas how to best do
this.
We have a set of bugs that we thought important enough to mark
10.2.2 at
one point and then they sort of got shifted to 10.2.3 and 10.2.4 (or
something like that - not sure). Is it time to shift them to 10.3?
I took a quick look at just the 10.3 bug candidates and cleaned up a
little - if I got it wrong, please feel free to update.
