[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office-formula] Handling of JIRA issues
It is clear to me that I can find defects without knowing how they should be resolved or even might be resolved. I might notice that something is underspecified, inconsistent, or that there is a contradiction with another provision without knowing what the correct resolution might be and what the original intention was when the provision was introduced. For example, I have no idea how to specify what is essential about a manifest.rdf document in an ODF 1.2 package, yet I can easily determine that there is not enough information for the implementer of a producer to be able to know the answer from the specification itself, which means that consumers won't know what to expect or count on either. Finally, the condition that editing of a document should preserve the RDF metadata is ridiculous, but providing a sharper statement is very difficult. (I understand it is only a recommendation in the JTC1 normative-language sense, but it is a very peculiar recommendation in this case.) The same thing happens with regard to, say, OpenFormula section 4.8 on Reference syntax. There is not enough information to know how a cuboid is determined in all of the variations, and what the additional requirements are for a cuboid to be determined. There's more. I could propose by guessing, like I did for the allowed text of passwords in order to be precise with regard to table:protection-key and table:protection-key-digest-algorithm, but it would be irresponsible for me to claim that this is a correct or even agreed resolution. In some case, I might be able to say what sort of action needs to be taken, but I would not know what are the correct specifics. The fact that someone doesn't raise their hand to fix it does not mean, to me, that a recognized, significant defect should receive a free pass and be "shipped." We might need to make a policy decision, declare the feature implementation-dependent, or something like that. I guess I could propose such resolutions. Does that seem satisfactory, if I or anyone else were to see an unowned issue about a substantive defect no one takes on? - Dennis -----Original Message----- From: Michael.Brauer@Sun.COM [mailto:Michael.Brauer@Sun.COM] Sent: Tuesday, April 20, 2010 03:57 To: dennis.hamilton@acm.org Cc: 'Eike Rathke'; 'OASIS ODFF SC' Subject: Re: [office-formula] Handling of JIRA issues [ ... ] I don't think that will happen. If something is really clearly a defect, then there should be some understanding how to resolve the defect. That's because some knowledge what would be correct is required to judge that something is a defect. I further strongly believe we are all interested in a good specification. If a particular improvement is considered to be important not only by the submitter of the issue, then there should be someone who cares. > > I suppose one resolution would be to remove whatever feature has the > unresolved defect, but that might not always be a very welcome solution. I > guess we need to see what actually comes up before we decide to tie our > hands in advance. We other option is to keep a particular detail implementation dependent. That's not a perfect solution, but I think on many cases better than dropping a feature. Michael > > - Dennis > > -----Original Message----- > From: Eike Rathke [mailto:erack@sun.com] > Sent: Monday, April 19, 2010 08:16 > To: OASIS ODFF SC > Subject: [office-formula] Handling of JIRA issues > > 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? > > Eike > -- 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 --------------------------------------------------------------------- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]