Re: [office-formula] Handling of JIRA issues

[Eike Rathke <erack@sun.com>]

Hi,

On Friday, 2010-04-23 10:35:17 +0200, Michael Brauer wrote:
> Am 21.04.10 21:12, robert_weir@us.ibm.com schrieb:
>> I think the problem is we have only two release fields in JIRA: Affects 
>> version and Fix version, while we really have four different concepts:
>>
>> 1) The version that the defect was reported against.  For example 
>> during a public review, this will be a single version.
>>
>> 2) Other versions of the specification that might be affected by the 
>> same defect

Affects Version (as well as Fix Version), can be multiply selected using
Ctrl+Click, I don't see any problem with that. The proposal text, if
necessary, could have different sections for different fix versions if
needed (e.g. for part1). If too complicated there's also the possibility
to create subtasks, which also helps to track resolutions for different
versions if they are applied at different points in time.

>> 3) The version we propose or target a fix for
>>
>> 4) The version we actually do put the fix in
>>
>> Because we only have two different fields, we need to express these 
>> four concepts by additional conventions.
>>
>> I don't mind if we set a fix target in the "proposed" sense, even 
>> without a resolution.  But if we do that, then we need to go back and 
>> reset this field for any defects that are not actually fixed when that 
>> new revision is approved.

Then we also need to agree that having a Fix Version set does not mean
we need to fix an issue for that version. But then again, setting
a target is just a proposal and quite useless.

>> The alternative, and maybe this is what you are suggesting, is that we  
>> don't set a fix version until we have a proposal ready to be 
>> integrated?

No, I say to set a Fix Version if someone actually wants to work on an
issue and provide a resolution, and either knows he'll do that for
a certain version or gives an issue enough importance and commits
himself to find a resolution until a specific version's due date.

> But the essential point behind Eike's proposal is to me that we need to
> know who cares about a resolution if we want to get an issue resolved.

Exactly.

> The TC consists only of its members. If no TC member volunteers to care
> about an issue, we can't resolve it. And it then also has no value to
> set a fix for field, even if we interpret this field as a proposal
> only.

This is the point.

  Eike

-- 
Automatic string conversions considered dangerous. They are the GOTO statements
of spreadsheets.  --Robert Weir on the OpenDocument formula subcommittee's list.

PGP signature