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: Draft Minutes 16th April 2014

Minutes 16th April 2014


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


      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


      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


          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.


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