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 Daniel John Debrunner <dj...@apache.org> on 2007/01/25 16:08:14 UTC
Derby handling of Jira's "Fix Version/s"- WAS Re: 10.3 wiki page
question
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.
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?
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.
>>
>>
>
>
Re: Derby handling of Jira's "Fix Version/s"- WAS Re: 10.3 wiki page
question
Posted by "Bernt M. Johnsen" <Be...@Sun.COM>.
>>>>>>>>>>>> Daniel John Debrunner wrote (2007-01-25 07:08:14):
> [...]
> 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?
+1
Especially, I think we should use voting more extensivley.
--
Bernt Marius Johnsen, Database Technology Group,
Staff Engineer, Technical Lead Derby/Java DB
Sun Microsystems, Trondheim, Norway
Re: Derby handling of Jira's "Fix Version/s"- WAS Re: 10.3 wiki page
question
Posted by Daniel John Debrunner <dj...@apache.org>.
Andrew McIntyre wrote:
> On 1/25/07, Andrew McIntyre <mc...@gmail.com> wrote:
>> On 1/25/07, Andrew McIntyre <mc...@gmail.com> wrote:
>> >
>> > Get ready for a JIRA blast. :-)
>>
>> Here goes, unmarking fix versions for unassigned issues...
>
> No JIRA blast necessary, the new version of JIRA allows turning off
> email updates for bulk changes.
Thanks Andrew.
Dan.
Re: Derby handling of Jira's "Fix Version/s"- WAS Re: 10.3 wiki page question
Posted by Andrew McIntyre <mc...@gmail.com>.
On 1/25/07, Andrew McIntyre <mc...@gmail.com> wrote:
> On 1/25/07, Andrew McIntyre <mc...@gmail.com> wrote:
> >
> > Get ready for a JIRA blast. :-)
>
> Here goes, unmarking fix versions for unassigned issues...
No JIRA blast necessary, the new version of JIRA allows turning off
email updates for bulk changes.
andrew
Re: Derby handling of Jira's "Fix Version/s"- WAS Re: 10.3 wiki page question
Posted by Andrew McIntyre <mc...@gmail.com>.
On 1/25/07, Andrew McIntyre <mc...@gmail.com> wrote:
>
> Get ready for a JIRA blast. :-)
Here goes, unmarking fix versions for unassigned issues...
andrew
Re: Derby handling of Jira's "Fix Version/s"- WAS Re: 10.3 wiki page question
Posted by Andrew McIntyre <mc...@gmail.com>.
On 1/25/07, Rick Hillegas <Ri...@sun.com> wrote:
>
> Daniel John Debrunner wrote:
> >
> > 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.
Agreed. I will unset the Fix Version on all Unassigned issues in a
couple of hours if I have not heard any disagreement.
Get ready for a JIRA blast. :-)
andrew
Re: Derby handling of Jira's "Fix Version/s"- WAS Re: 10.3 wiki page
question
Posted by Rick Hillegas <Ri...@Sun.COM>.
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.
>>>
>>>
>>
>>
>
>