Time: 10:00AM Eastern US (contact MichaelFiedler if you'd like to participate)

The Automation meetings alternate times each meeting to accommodate the global team.

Agenda

* Main agenda items:

• Review workgroup status after 2 week break
• Asynchronous automation scenario - continue to discuss options.
  • Review previous options
  • Discuss new option proposed by JohnArwe : AutoSynchAttributeOptions
• Mailing list issues - summarizing here since the formatting in the mail archive is pretty poor
  • Do we need an automationType attribute on plans? or on the provider? pro: possibly gives consumers "hints" con: makes automation less generic
  • oslc_auto:state/oslc_auto:verdict Are the states and verdicts currently in the spec sufficient and is their usage in the artifacts clear?
• Specification status and Implementation plans
  • update vocabulary to match spec
• Next meeting:
  • Thursday, 21 June at 1PM Eastern US

Minutes

Attending: Michael Fiedler, Steve Speicher, Paul McMahan? , Pramod Chandoria, Charles Rankin, David Liu, Thomas Spatzier, Vaibhav Srivastava

* Reviewed workgroup status. Agreement spec can be considered in convergence once synchronous execution approach is agreed upon.

* Reviewed option 4 in AutoSynchAttributeOptions

• general agreement - need to add it to the spec and socialize on the mailing list
• final open issue is Location header in response to successful POST of an Automation Request when the response contains a result and there is nothing persisted for the Location header to refer to.
  • HTTP spec says a 200 is appropriate if the POST does not produce something which can be referred to by a URI
  • Options
    • Use 201 without a Location header (goes against HTTP spec)
    • Use 200 (requires consumer to distinguish between 200/201
    • Use 201 and provide a "dummy" Location (likely goes against HTTP)

* Mailing list issue on whether we need a type for Automation Plans (e.g. test, build, deploy, etc)

• General feeling that this removes flexibility and we don't know enough at this time to enumerate plan types
• Agreement that providers wanting to do this can do it via multiple rdf:type statements until we have more implementation experience

* Mailing list issue on whether state should be "exactly one" or "zero or one" on Automation result

• Due to flexibility in deciding when in the execution lifecycle Automation Results might be created, some providers may do primary tracking of lifecycle state in the Automation Request rather than the Result
• No arguments against making it "zero or one" - does create an asymmetry with Requests
• Decision was to tentatively make it "zero or one" in the spec and continue discussion on list.

* Implementation update

• Rational Quality Manager - provider and consumer under consideration for next release
• Rational Team Concert - Need and update from Nick Edgar
• Rational Build Forge and RAFW: Mike Fiedler will contact product management
• Tivoli - Need an update from John Arwe
• Eclipse Mylyn - will be a consumer
• Eclipse Hudson - Mike Fiedler to contact the Hudson lead
• Need a reference implementation in Eclipse Lyo for consumers to test with
• Need a test suite in Eclipse Lyo for providers to test with