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

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

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


Subject: Re: [office] ODF-Next Proposal


Hi Dennis,

On 19.01.2011 20:18, Dennis E. Hamilton wrote:
I think this is an effective procedure.  I only have two non-substantive observations.

1. Although it is useful to set deadlines in JIRA (I think these will show up on the assignees overall JIRA overview page), I agree that targeting to specific CSD01, CSD02, CSD03 will be helpful in managing this as well.  I assume that
Good point. So far I did only know JIRA's "version" feature. It allows to define "versions", and one may define a "release date" for a version. By setting a "fix for" field of a particular issue, that issue indirectly gets a due date.

But I just realized that there is also a "due date" feature.

Both fields are searchable in queries. So both fields may work. I right now have no strong preference for the one or the other. But if we don't find any advantages for using "due date", I would say let's take the "fix for" field, since that is what we are familiar with.
 CSD04 will also be a target, but its use will be constrained by the procedure as you have described it.  In any case,
Yes.

 I think it would be good to continue the CSD series (i.e., start with CSD08 rather than CSD01 assuming that CSD07 is the last one before we take ODF 1.2 to Committee Specification 01).
  
I personally don't mind if the next draft is called CSD01 or CSD08, but my reading of the OASIS naming guidelines is that after an OS, we need to start with a new version (as defined be naming directives), and for that version, we need to start with CSD01 again.
2. In other organizations, I have seen discussion of version xx-bis (or RFCyyyy-bis in the case of IETF standards-track RFCs) while working on a future version that is not yet stabilized.  That apparently doesn't work for OASIS.  However, we could talk about ODF 1.2 edition 2 apparently, until we decide what we are really working on and switch over before going to Committee Specification.
  
The naming directives state: "A Version in this formal sense must be represented textually by a numeric string composed of digits [0-9] and period (".") corresponding to any of the approved lexical models (#.#, e.g. 1.0; #.##, e.g. 1.01; #.#.#, e.g. 1.2.1; ##.#, e.g. 10.1). Use of any other pattern for a Version identifier must be negotiated with the TC Administration."

My reading is that neither an "1.2-bis" nor an "1.2 edition 2" are covered by this, but in both cases we may negotiate the identifier with the TC administration.
Since we had already an ODF 1.0 2nd edition, which contained only editorial changes compared to ODF 1.0, I think we should not reuse this naming pattern. But if we find reasons that seem to be good enough to justify asking for an exception to use a name outside the allowed lexical models, we may do so.

The business about provisional implementations is another matter beyond this topic.  Perhaps there is something the OIC can do to advise safe practices for implementers and users that will avoid any problems.
  
I agree that this is another topic, but I don't think there is a solution that avoids "any" problems. And it is a larger topic actually. Implementations may not only change because the ODF spec changes, but also because issues get corrected, or because implementors interpret the specification differently. From all that, the issues that are caused by changes to the spec probably will be outnumbered by the other classes of issues.

Best regards

Michael

 - Dennis

-----Original Message-----
From: Michael Brauer [mailto:michael.brauer@oracle.com] 
Sent: Wednesday, January 19, 2011 09:16
To: OpenDocument Mailing List
Subject: [office] ODF-Next Proposal

Hi,

as promised, here is a revised proposal for the development of ODF-Next. I've tried to integrate the feedback I've received on my first suggestions, and have grouped the proposals into general things about the next ODF version, the schedule, and proposals how to use JIRA.

I welcome your feedback, but would like to ask for two things if you disagree to a particular item: 1) Please indicate whether you agree to the other items, and. 2) Please provide an alternative suggestion.

I have intentionally left out the question of whether we encourage vendors to implement CSDs, since this is, as Rob correctly noted, out of our control.

I have further intentionally left out the question whether or not we want to identify the CSD numbers in documents, and if so how. This is a question that best is discussed as a proposal for ODF 1.3.

General
- For now, the version number (as defined by the OASIS naming directives) for the next version is "1.3" (but that's not necessarily the value of the office:version attribute). However, the version number may be changed to "2.0". This may be because the TC agrees on a change that makes the next ODF version incompatible with ODF 1.2, or because of major enhancements, or other not yet known reasons.
-  ODF 1.3 for now will remain backward compatible with ODF 1.2, except that individual features may be incompatible. That is, an ODF 1.2 implementation shall be able to read ODF 1.3 documents. But for some ODF 1.2 features or elements/attributes, there may be improved variants in ODF1.3, and these may not be backward compatible. Like any other proposal, a proposal for backward incompatible changes requires an (informal) approval by the TC (see also below). Actually this is not different than what we did for ODF 1.2.
- The TC may revise this decision that ODF 1.3 is backward compatible with ODF 1.2 based on individual proposal for changes. That is, the TC decides that ODF 1.3 (or 2.0, as it may be called then) shall get incompatible to ODF 1.2 in general if and when it gets a proposal that includes an incompatible change.

Schedule
- ODF 1.3 will be developed as a sequence of committee specifications. Committee specifications shall be ready for approval by the TC every 6 months. 
- The first committee draft (CSD01) shall be ready for approval in September 2011, CSD02 in March 2012, CSD03 in September 2012 and CSD04 in March 2013. 
- CSD04  shall be advanced to an OASIS standard. It may be approved earlier than March 2013 if no proposals or severe issues are outstanding.
- Before a committee draft is approved, there shall be a period of 2 months where no proposals are integrated.
- Between CSD03 and CSD04 no new features shall be integrated into the ODF specification. Which means that the last month where features may be integrated is July 2012. Exceptions from this rule shall be granted only if the TC is confident that the new feature does not break, and that it further gets implemented.

JIRA/Feature approval process
- The progress of proposals shall be tracked in JIRA.
- New "fix for" fields "ODF 1.3 CSD1", "ODF 1.3 CSD2", "ODF 1.3 CSD3" and "ODF 1.3 CSD4" will be created. With the exception of "ODF 1.3 CSD04", these targets may be set by TC members at any time, but only if the issue is assigned to a TC member who feels responsible for advancing the proposal into a state where it can be integrated into the specification within the timeline for the chosen target.
- Proposals shall only be integrated if they contain the text and schema changes that shall become part of ODF 1.3, or at least enough information that the TC editor can prepare the text and the schema, and if no objections have been raised to the proposal in JIRA. If objections are raised, A TC member can request a formal vote to include the proposal.
- If a proposal is not in that shape 2 months before the planed approval of a CSD, it will be deferred to the next CSD. "ODF 1.2 CSD3" issues will only be deferred to "ODF 1.2 CSD04" if the TC grants an explicit exception for this.
- TC members can raise objections to a proposal by a "-1" comment, or agreement by a "+1" comment.
- Proposals are only discussed in a TC call if they get a component "Needs discussion" assigned.
- JIRA issues for proposals shall only be opened if the work on a proposal starts.
- JIRA issues that contain a complete proposal shall be set to resolved. They may be integrated into the specification if no objections is raised to the issue within one week.
- All voting within a JIRA issue is informal and preliminary. The formal approval of  proposal takes place when a CSD that includes the proposal is approved (that's a consequence of the TC process, but it is worth mentioning this).
- Proposals approved in a CSD may be modified by follow-up proposals for a subsequent CSD.

I hope I didn't miss anything.

Best regards

Michael





  

--
Oracle
Michael Brauer | Oracle Office Development
Phone: +49 40 23646 500 | |
Oracle Office Global Business Unit

ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg


ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Rijnzathe 6, 3454PV De Meern, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven

Green Oracle Oracle is committed to developing practices and products that help protect the environment


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