[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 understanding. 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 only. 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. Michael > > -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 StarOffice/OpenOffice.org Sun Microsystems GmbH Nagelsweg 55 D-20097 Hamburg, Germany michael.brauer@sun.com http://sun.com/staroffice +49 40 23646 500 http://blogs.sun.com/GullFOSS 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]