db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: Jira field definition clarification for Derby
Date Mon, 31 Jul 2006 16:08:00 GMT
Kathey Marsden wrote:
> Recently there have been several discussions about the meaning of many
> of the Jira fields.
> Affects Version - The earliest release where the issue  is known to
> exist as shown by sysinfo.
> RESOLVE: What should this mean for non-bug issues?
> Fix Version  for Closed Issues -
> The earliest release where the  fix has been  made and forward ported to
> all higher rev maintenance branches and the trunk.
> The assumption is that you can move to  the latest of a higher rev 
> maintenance  branch  and get the fix.  For example  if the current trunk
> version is 10.2  and the fix is in 10.0 , but not in 10.1,  the issue
> should just be resolved with Fix Version 10.2 and  a comment added for
> the special backport. Of course fixes that have not been fixed in the
> trunk should not be marked resolved.

So Jira is one of the few bug tracking systems I've worked with that
allows multiple affects and fix-in versions, but this proposal seems to
be insisting on a single value in each of the "affects" and "fix"
version fields. I don't think this is a good approach, how would these
situations be handled?

1) Bug can be seen in, but not

2) Bug has been fixed in 10.2 and someone back ported it to but
it still exists in the 10.1 line?

3) Users see a bug and and useful information to the affects field to
say "Yes - I also saw this bug in this other release".

I think you are saying 2) would be handled with a "special comment", I
see that as unworkable, they can't be searched on, it's not obvious to
others that they should be looking for such comments. The fix version
field is the obvious place to store this information.

Why not use the power of the tool?

> (Note: The current practice of marking multiple fix versions creates
> problems with release notes and doesn't make sense because  you should
> really then mark fixin 10.3, 10.4 etc...)

Not sure I understand what you are trying to say here. If the problem of
handling multiple versions is in generating the release notes, then
that's the process that should be fixed.

> If this looks like a good start at definitions I can put it on the Wiki
> and then we can refine.

This is a great start.


View raw message