[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. > > TOPIC: AOB > > 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]