[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft Minutes 16th April 2014
Minutes 16th April 2014
Attendees:
Software AG, Inc. Bhaskar Reddy Byreddy Voting Member
Oracle Martin Chapman Chair
Cloudsoft Corporation Limited Alex Heneveld Voting Member
Rackspace Hosting, Inc. Adrian Otto Chair
Vnomic Derek Palma Voting Member
Oracle Gilbert Pilz Voting Member
Fujitsu Limited Tom Rutt Voting Member
Intro:
TOPIC: Roll Call
Attendees listed above. Voting Members: 7 of 12 (58%) (used for quorum calculation) meeting is quorate
TOPIC: Agenda
resolution: Agenda Approved
TOPIC: Meeting Minutes (April 9th, 2014)
9th April 2014: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201404/msg00009.html
MOTION: Move to approve the minutes of April 9th, 2014 m: Gil, s: Adrian
resolution: minutes approved
TOPIC: Administrivia
Martin> I'll be on a plane or thereabouts during next weeks meeting
? either we cancel or find a pro tem chair
Alex Heneveld: +1, cancel next week
Adrian> in the absence of compelling business we should just regroup in a couple of weeks
resolution: next weeks meeting is cancelled
Participate in our OASIS Cloud Standards Showcase at Cloud Expo East: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201404/msg00014.html
Martin> email from Jane about Cloud Expo, not sure what this is about as doesn't look like TC business.
TOPIC: Editing Team update
Gil> I uploaded a new metadata package to resolve CAMP-170
TOPIC: CAMP-168
https://tools.oasis-open.org/issues/browse/CAMP-168 requirment_type is confusing for implementers
Gil> there is a proposal up, people need to review it
Adrian Otto (Rackspace): I am requesting input from two stakeholders I work with
Adrian Otto (Rackspace): one just returned from vacation
Alex> we need to get this right
? perhaps Adrian, Gil, and myself can get together
Adrian> Devdatta just got back from vacation. He could join
Martin> We need to get this right and we're under no time pressure
TOPIC: CAMP-169
https://tools.oasis-open.org/issues/browse/CAMP-169 CLONE -Feedback/Questions on CAMP Version 1.1 Working Draft 32 (Dated: 5 December 2013)
Martin> we have a difference of opinion over this
? it has been deferred based on a previous TC decision
? re-opening it would require a super-majority
Gil> I made this proposal more out of curiosity than anything else
? "what would the spec look like if we did this?"
Alex> is the idea that the spec would be simpler if you couldn't reference a nested Service Spec
Martin> you can't use a nested Service Spec as a target of a reference
Adrian> You are both right. It requires less explanation this way
Alex> The reason I would opposed to this change is that, for simple applications it makes sense, but for more sophisticated applications (10 different sub-systems, each with several components), it is a lot nicer if you can draw this as a tree instead of one, big list.
? Inevitably there will be references between the requirements and the services. This makes the spec simpler, but actual instances of Plans more complicated.
? This will make the spec harder to work with.
? Machines don't care either way. Humans either ...
Adrian> Gil and I, when working on this, recognize your point of view. It seems the spec would benefit from examples that illustrate what you are talking about.
Alex> We do need some better worked examples. I don't have a lot of bandwidth to do the first cut at this.
Adrian> A real-world sanitized example, or a hypothetical
Alex> I would like to use real-world, but the things I know of are not public
? Best thing would be to work through a sequence of examples that start simple and get more complicated - as the heart of the primer.
? I could take a first cut at doing that. At least a proposed sequence of examples.
? Does anybody else have ideas for interesting examples?
Martin> I can understand a use case where you have a Plan file, bits of Plan files, etc.
? If we have this restriction it seems like you have to do a lot more cutting & pasting.
? I think that is a compelling use case.
? Tacking on an id and adding a reference is much easier.
Adrian> An alternative approach might be not to *show* an example using referenceable, embedded service specs
? don't prohibit them, but don't highlight their use
Adrain> that makes sense, keep silent on it
Gil> tension is between what goes in main spec and what goes in primer
? if we could make the primer appear tomorrow, this wouldn't be an issue
? the problem is that we don't want to confuse developers in the period between now and when the primer appears
? Adrian's suggestion takes some of the pressure off in that we don't draw attention to this feature until we can properly describe in in the primer
Martin> we shouldn't confuse documentation with features
Alex> we are going to want, in the next version, is the ability to reference/include one plan file from another plan file
? that is going to be another way of solving the "complex applications" use case
? we have to think about being compatible with whatever we do in the next version
? leaving IDs in gives us a leg up
Martin> I want to focus on the spec
? should it be in or should it be out?
? primers, explanatory text etc. is well and fine
? but we need to decide on this issue
Adrian> table discussion pending further input from Alex?
? we don't want to act in haste and remove features which are helpful
Alex> we have an obligation to have some good material around this spec
? I've been asked by people if we have an updated deck
Martin> I'm okay if we start work on the primer
? but I don't want to hold up work on the spec
? Alex, if you could provide some example that would be good
Alex> can we move to create a primer work product
Martin> we can do that, we need editors
? I'm assuming it would be a Committee Note
Adrian> we've brought up the subject of primer numerous times, no one has ever objected
? lets move on this and get working
Martin> we should think about this
? we need a title, etc.
? and an abbreviation
? "CAMP v1.1 Primer"?
Alex Heneveld: +1
MOTION: create a new work product called "CAMP Primer v1.1", that will be a non-standards track document deliverable, with the abbreviation of "camp-primer", that will contain non-normative material that will describe the use and implementation of CAMP v1.1
m: Alex, s: Adrian
Editing team is Alex, Adrian, and Gil
resolution: motion passes by UC
TOPIC: Any Other Business
No stragglers today.
MEETING ADJOURNED
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]