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


Help: OASIS Mailing Lists Help | MarkMail Help

camp message

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

Subject: Re: [camp] Draft minutes 13th November 2013

There is an error in the list of issues to be closed with no action; issue 143 was transposed as issue 148.

We need to re-open issue 148 and close issue 143.

~ gp

On Nov 14, 2013, at 8:14 AM, Martin Chapman <martin.chapman@oracle.com> wrote:

> Minutes 13th November 2013
> Attendees:
> Software AG, Inc.			Bhaskar Reddy Byreddy	Voting Member
> Oracle				Mark Carlson	Voting Member
> Oracle				Martin Chapman	Chair
> Fujitsu Limited			Jacques Durand	Voting Member
> Cloudsoft Corporation Limited	Alex Heneveld	Voting Member
> Oracle				Anish Karmarkar	Voting Member
> Oracle				Ashok Malhotra	Voting Member
> Rackspace Hosting, Inc.		Adrian Otto	Secretary
> Oracle				Gilbert Pilz	Voting Member
> Fujitsu Limited			Tom Rutt		Voting Member
> Software AG, Inc.			Prasad Yendluri	Voting Member
> Intro:
>      Roll Call:  Voting Members: 11 of 12 (91%) meeting is quorate
>      Topic: Agenda approval
>             Redfining the order of the issues discussion
>             Anish Karmarkar: discussing CNAs first would be good
>             add new issue: https://tools.oasis-open.org/issues/browse/CAMP-150 
>             Approved as modified.
> Minutes:
>      6th November 2013: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201311/msg00041.html 
>          Correction needed the minutes approved were for the 30th october 2013.
>          Motion Gil, s: Ashok approve minutes of the 6th fixing the reference to past minutes to 30th October 2013
>          Passed w/o
>      Topic: Scrum sessions notes availabale - informal so no need to approve:
>           Session 1: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201311/msg00051.html 
>           Session 2: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201311/msg00078.html 
>           Session 3: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201311/msg00094.html 
>            Anish: observes the meetings were very useful
> Topic: Action Items
>      None
> Topic: Editing Team Update
>      Gil: Pushed out WD 29: https://www.oasis-open.org/apps/org/workgroup/camp/document.php?document_id=51313 
>      Jacques: New version of test assertions doc by next week
> New Issue:
>       https://tools.oasis-open.org/issues/browse/CAMP-150  mechanism for creating an Assembly (or Plan) by value (i.e. POSTing the contents of a PDP or Plan file) is difficult to use
>      Anish Karmarkar: note, we do have a high bar for new issues
>      MartinC: 2/3 majority
>      Gil: Need to fix this sooner than later
>      .. proposing this to be a P1 issue
>      Alex Heneveld: +1 we need to do this
>      Use a multi-part data format
>      Adrian Otto (Rackspace): +1 this is a good improvement and will aid adoption. I think forming and approving a proposal for this will not be difficult.
>      Anish: Things will look complicated on the wire due to multi-part but 
>      ...you are not dealing with raw messages but APIs etc. May be ok
>      Anish Karmarkar: agree with @adrian, proposal would be easy
>      Motion: Gil moves to open 150 as P1 second Adrian
>      No objections. 150 is open
> Issue Discussion:
>      Martin: Summarized the issues into 3 groups (some errors)
>      Anish Karmarkar: my suggestion: deal with P1 first then the CNA group
>      We have two P1s with proposal 86 & 80
>      Issue:  https://tools.oasis-open.org/issues/browse/CAMP-86 
>        modified proposal in JIRA: [YAML 1.1] Oren Ben-Kiki, Clark Evans, Brian Ingerson, "YAML Ain't             
>       Markup Language (YAML) Version 1.1, 2005-10-18" http://yaml.org/spec/1.1/ .          
>      Also archived    at: http://xml.coverpages.org/yaml-spec-v1.1-archive-copy.html 
>         Motion to resolve 86 with the proposal in Jira: mov: Adrian: Sec: Tom
>         Motion Approved w/o
>      Issue: https://tools.oasis-open.org/issues/browse/CAMP-80 
>      Gil: Presents the issue..
>      Anish Karmarkar: this should be easy. We now have multiple URLs to post to. By ref is       
>      always json. By value is based on what you are posting: yaml has yaml media-type, zip has        the appropriate zip media type and so on
>      Anish Karmarkar: note that this may change based on resolution of 150
>      Anish Karmarkar: with the introduction of multipart
>      Anish Karmarkar: in which case would just talk about the root part in the multipart
>      Anish Karmarkar: the nice thing about multipart is that by-ref and by-value are equivalent as both can now have parameters
>      .. and proposed resolution
>      Anish: likes the proposal but issue 150 might change it ..
>      Alex: Likes the proposal
>      MOTION: Gil: Moves to resolve issue 150 the proposal in Jira S: Tom
>      Approved w/o
> Issues with proposals to close with no action:
>      Issue: https://tools.oasis-open.org/issues/browse/CAMP-147 
>      Issue:  https://tools.oasis-open.org/issues/browse/CAMP-143 
>      Issue: https://tools.oasis-open.org/issues/browse/CAMP-114 
>      Issue: https://tools.oasis-open.org/issues/browse/CAMP-88 
>      Issue: https://tools.oasis-open.org/issues/browse/CAMP-84 
>      Issue: https://tools.oasis-open.org/issues/browse/CAMP-79 
>      Issue: https://tools.oasis-open.org/issues/browse/CAMP-42 
>      Issue: https://tools.oasis-open.org/issues/browse/CAMP-11 
>      All above are P2s
>      P3:
>      https://tools.oasis-open.org/issues/browse/CAMP-69 
>      Issue: https://tools.oasis-open.org/issues/browse/CAMP-59 
>      Issue: https://tools.oasis-open.org/issues/browse/CAMP-27 
>      Ashok: Scaling Policy, Alex talked about sending us an example.
>      Alex: I am happy to send the example, we can keep the issue open but I don't think it belongs in the spec
>      Ashok: I am happy to close the issue but like see the example AI
>      Motion: Ashok moves to close all the issues listed above with no action,     second: Anish
>      issus: 147, 148, 114, 88, 84, 79, 42, 11, 69, 59, 27
>      Motion approved w/o objections
> Issue: https://tools.oasis-open.org/issues/browse/CAMP-62 
>      Gil: Explains the issue and proposal
>      MartinC: note this was an action from the scrum so the proposal was not agreed in the scrum per see
>      Anish: we are stuck with JSON types and 
>       ...  The order is relevant
>      ...if the client or provider does not maintain that order unexpected things can happen   wrt issue resolution, should we just stay silent?
>      Tom: Sympatise with Gil. But..
>      What is the scope of this across multiple HTTP requests?
>      Anish: You are asking reg. reboots and patch etc. We already say you should do conditional updates
>      .... You do a get prior to update but, if things change (e.g. reboot after get) if not      
>       .... sure resources  are in the same order, you should do a conditional update, i.e. update only if things are the same as befopre.
>      Adrian: I am not clear on the problem..
>      Anish Karmarkar: i'm more inclined to CNA this
>      Anish Karmarkar: don't mess with the order
>      Gil: the issue stems from my impl. experience
>      Anish Karmarkar: if you mess with the order bad things will happen
>      Adrain: Are you providing advise but not placing restrictions in the spec?
>      GiL: I am asking for restrictions
>      Adrin: why use soft lang. like advise..
>      Anish: We have already said order is relevant (saying something restrictive already)
>      .. we already have a strong language
>      Alex: This has never been an issue before but it might become ..
>      It is technically not necessary but, this should go in the primer not the spec
>      we should state the problem more precisely..
>      discussing tweaking proposal text
>      Gil: contemplates aloud the wisdom of putting in the spec or in a primer
>      Anish Karmarkar: if we wanted to say something stronger (as suggested by Adrian) we could      
>       ...say: "Providers SHALL preserve the order of the elements in JSON arrays across        HTTP requests when there is no change to the array"
>      Tom: the last sentence (the advise) should not be part of the spec, it is the confusing part
>      Anish Karmarkar: or something like that
>      Gil: suggests to close with no action and take it up in the primer
>      MOTION: Gil: Moves to close issue 62 with no action. Second: Adrian
>      Approved w/o objections. Isues 62 is close with no action
>      Issue: CAMP 74     https://tools.oasis-open.org/issues/browse/CAMP-74 
>        Gil: Elaborates the issue
>          Tom: section 2.3 needs to be updated
>          Tom Rutt (Fujitsu): need to update 2.3
>          Anish Karmarkar: i like this proposal
>          Anish Karmarkar: this is a very clever way
>          Anish Karmarkar: it reduces the number of ways to do the same thing
>         Anish Karmarkar: to one
>         Tom Rutt (Fujitsu): change sentence under fig 2-6 On platforms that choose to support Plans,           
>          ... a CAMP Consumer can create a Plan resource by uploading either a PDP or a Plan file to the            
>         .... Plans resource URI using an HTTP POST request.
>         Tom Rutt (Fujitsu): to
>          Tom Rutt (Fujitsu): On platforms that choose to support Plans, a CAMP Consumer can create
>            .... a Plan resource by uploading either a PDP or a Plan file to the Assemblies resource URI using   an HTTP POST request.
>      Gil: Still need to update the proposal
>      MOTION: Gil: motions to approve Jira proposal with Toms' suggested modification above, Second: Tom
>      Approved w/o objections. Issue 74 is resolved.
>      Straggler: none
> Meeting Adjourned
> ---------------------------------------------------------------------
> 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]