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

Am 21.04.10 21:12, robert_weir@us.ibm.com schrieb:
> 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.

Both works for me, but it essential that we all have the same

And if we consider the "Fix for" field as a proposal, then we must
consider it really as a proposal. That means, it must be uncontroversial
that we reset the value of a field if an issue is not resolved in the
proposed version. And it must also be uncontroversial that we may
approve a version of the specification even if we have issues that are
proposed to be resolved in that version.

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.
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

Since you've mentioned SC34 defects: You are right that we don't assign
the corresponding issues to TC  members. But this works in that case
because Patrick and Svante are responsible for the erratas. So, in
practice, these issues are assigned to them. We only do not reflect this
in JIRA, although we should.

> 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.

Yes, that would be reasonable. We are indeed using the "fix for" field
inconsistently. For the formula SC we are using the field more in the
meaning of a proposal. But for the public review comments and issues we
are setting the field mostly if we resolve issues.

The more I think about, I start to believe that it is best to set the
"fix for" field only if we have a resolution, with the exception maybe
that we use ODF-Next as target for issues or improvements that we have
clearly identified as something for a follow-up version.

That should work in all situations:
For SC34 defect reports we have queries that cover these issues. We
don't need a "fix for" field to know that we want to resolve these
issues in the next errata.

For public comments (or issues submitted by TC members during the public
review), we have well defined values for the "affects" field. We don't
need "fix for" here as well.

All other issues are submitted by TC members. If the submitters of these
issues want to track the progress of these issues, they can easily find
these issues by searching for the issues they have submitted (Rob, you 
may have an issue with this since you are importing the public 
comments). And one of cause can also find issues of interest by 
searching for assignees or adding particular keywords.


> -Rob
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

Michael Brauer, Technical Architect Software Engineering
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
	   D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Jürgen Kunz

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