db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: [jira] Commented: (DERBY-528) Support for DRDA Strong User ID and Password Substitute Authentication (USRSSBPWD) scheme
Date Thu, 15 Sep 2005 21:01:58 GMT
Francois Orsini wrote:

> Thanks for pointing that out Dan. So I take it that new features at this
> point should be targeted at 10.2.0 _if_ we want them to be in the next
> release that includes new features - right?

Easy answer, yes.

However, it's not clear to me that we are treating the 'FixIn' field
consistently, or even if it matters. :-)

Does it mean 'it was fixed in', or 'I'm planning/want to fix in
in', or both depending on if the bug is fixed or not.

If it's the former then the value is only filled in when the bug/issue
is fixed and the value should come from running sysinfo in the line
where it is fixed. Thus if you fixed 528 today in the trunk then the
fixin version would be

Of course the trouble comes, as with (almost) every other defect
tracking system I've used, with the fact a bug can be fixed in multiple
code lines, but the tool cannot represent that. E.g. for a bug, its real
state may be

10.0.x.y - does not exist
10.1.x.y - exists and need to be fixed - fixed

Jira doesn't seem to support this, unless maybe sub-tasks are used.


View raw message