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] Tying issues to committee drafts


"Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 06/02/2009 
12:03:27 PM:
> 
> RE: [office] Tying issues to committee drafts
> 
> I'm confused.  I thought cd02 (aka cd01 rev06) is what we are currently
> reviewing and we will likely see cd02 rev01, cd02 rev02, etc., until we
> decide to declare one of them cd03.  That was the pattern in moving from
> initial cd01 to declaration of cd02.
> 

That is the pattern that OASIS asks us to follow.  We have revisions of a 
CD until the new CD is approved, etc.

> I assume that you apply a resolved issue (in JIRA parlance) when you 
have
> actually made the changes to the draft (revision) you are working on.
> Although technically, it would not be fully applied until it survived 
into
> an approved cd?
> 

I think that is the intent.  JIRA is for tracking issues.  It is not an 
approval mechanism.  Meeting minutes are for recording what the TC 
approves or doesn't approve, and these decisions for the most part are 
batched into CD approval votes.  The main thing we want JIRA to track is 
the textual emendation of the current working text to include the stated 
resolution of the issue. 

What would help is if Patrick (or anyone else resolving issues) would note 
what revision a particular issue is resolved in.  Right now I have 
"releases" for ODF 1.2.  I could define releases for ODF 1.2 - CD02Rev6, 
CD02Rev7, etc.  Or we could just track that information in the comment 
field as we go.


> (This reminds me of checking code into a build.  The code is not 
deployed,
> however, until a release is cut.  There is usually some regression 
progress
> to determine that a change survived properly into the release.   The 
release
> notes would reflect all fixes since the previous release regardless of 
the
> build in which they were first checked into.  I'm not sure how the 
analogy
> works for us, although it seems that quality assurance of our 
specification
> development has parallels, with the complication of movement from cd
> sequence to a cs sequence to an os progression.) 
> 
> It seems that it is either possible 
> 
>   (1) that the resolution of an issue is applied more than once 
(progressing
> through drafts that preserve it) or 
>   (2) we understand that a cd includes all changes applied to 
intermediate
> drafts since the previous cd (including any reversions/replacements of
> changes)
> 
> It might come down to how filtering works best?
> 

I think we have (2) above.  The JIRA filtering mechanism should allow us 
to filter on release = ODF 1.2 to produce a master list of changes, or to 
do a free-text search in the comment fields for a particular CD revision 
if we care to track that.  For example, we should be able to produce a 
list of all issues fixed in ODF12-Rev6.

-Rob

>  - Dennis
> 
> -----Original Message-----
> From: Patrick Durusau [mailto:patrick@durusau.net] 
> Sent: Tuesday, June 02, 2009 06:52
> To: ODF office
> Subject: [office] Tying issues to committee drafts
> 
> Greetings!
> 
> I would like to suggest that a *placeholder* be created for the next 
> committee draft version be created in JIRA so that as I "apply" 
> resolutions, I can assign those issues to that particular committee 
draft.
> 
> Note that such a draft does not *yet* exist but that will tie a 
> particular set of issues to a given draft, such that when that draft is 
> approved by the committee, it is possible to know what issues were 
> addressed by that draft.
> 
> It is certainly the case that if in the approval process an issue needed 

> further discussion or revision, its assignment could be changed so that 
> it isn't tied to that committee draft.
> 
> We are now at: OpenDocument-v1.2-committeeDraft-01 so I would suggest 
> the placeholder for the next version would be:
> 
> OpenDocument-v1.2-committeeDraft-02.
> 
> I think that would tie the issues to particular releases with the 
> minimum amount of effort.
> 
> Comments/suggestions?
> 
> Hope everyone is having a great week!
> 
> Patrick
> 
> -- 
> Patrick Durusau
> patrick@durusau.net
> Chair, V1 - US TAG to JTC 1/SC 34
> Convener, JTC 1/SC 34/WG 3 (Topic Maps)
> Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
> Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)
> 
> 
> ---------------------------------------------------------------------
> 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 
> 
> 
> ---------------------------------------------------------------------
> 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]