OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-formula message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office-formula] Handling of JIRA issues


Eike Rathke <erack@sun.com> wrote on 04/19/2010 11:15:57 AM:

> Hi,
> 
> Since we're nearing CD3 and following that the hot phase of a public
> review, I'd like to propose a handling of JIRA issues until CD3 and
> review:
> 
> New and unassigned issues may not have a ODF 1.2 (CD3 or final) target
> set unless
> 
> a) Someone commits himself to resolve the issue for a specific target.
> 
> b) The TC/SC agrees on a target for the issue AND finds someone for a).
> 
> Following that, of course it is valid to submit an issue, regard it
> important enough for CD3, resolve it and target it to CD3.
> 
> However, it is invalid to submit new issues and target them to CD3 if no
> one committed on resolving the issue.
> 
> Otherwise having the target doesn't make sense.
> Opinions?

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

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.

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? 
If we do that, then we need another way to indicate which JIRA issues are 
proposed for which version.  In the case, for example, of SC34 defect 
reports, we know we will respond to them in the next Errata, and we know 
that even before we have an owner or resolution for these issues.

So, if possible, I'd like us to adopt a convention that works for all 
parts, not just for OpenFormula, and that makes sense for ODF 1.2, as well 
as errata, etc.  But I don't know of that is easily done.

-Rob


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]