This wiki is locked. Future workgroup activity and specification development must take place at
our new wiki
. For more information, see
this blog post about the new governance model
and
this post about changes to the website
.
TWiki
>
Main Web
>
AutomationHome
>
AutomationMeetings
>
AutomationMeetings20120628
(10 Jul 2012,
MichaelFiedler
)
(raw view)
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: * Specification issues * [[AutomationStateVerdictIssues][Automation State and Verdict open issues]] * Specification comments/questions * Specification review comments * Specification status and Implementation plans * update vocabulary to match spec * Next meeting: * Thursday, 12 July at 10AM Eastern US ---+++ Minutes Attending: Michael Fiedler, Charles Rankin, Jing Qian, Steve Speicher, Amy Yu, Robert Elves, Paul McMahan * Specification issues * Agreement on changes to the spec re: proposed verdict changes. Spec will be updated to reflect the discussion * State * Discussion on which states should be looked at when both Automation Requests and Results are active * Answer is really both. Common patterns may exist (e.g. Look at Request until it is =oslc_auto:complete= and then look at Result), but this may depend on service provider implementation. State of both artifacts should be considered by the consumer. * State consistency * Need language in spec to make state consistency a MUST. Specifically, when a Result is complete, the associated requests must also be complete. Other state consistencies are likely a SHOULD - i.e. should not have queued Request when a Result is in progress. * Guidance on cancellation * Add section to service provider capabilities with guidance on cancellation. If the Request is not complete, cancel the request. If the Request is complete and the Result is not, cancel the Result. * Automation type * Some workgroup members see clear scenarios where automation type (build, test, deploy, etc) at the provider level is needed. Main scenario is around where context in a tool's UI might require knowledge of an automation provider's "type" in order to make a sensible choice. * Implementation news * Several groups starting to plan implementations, details will be reported as available * Eclipse Hudson interest * IBM Rational: Quality Manager, Team Concert, Build Forge, possibly others * IBM Tivoli: Details TBD * Others under investigation
E
dit
|
A
ttach
|
P
rint version
|
H
istory
: r3
<
r2
<
r1
|
B
acklinks
|
V
iew topic
|
Ra
w
edit
|
M
ore topic actions
Topic revision: r3 - 10 Jul 2012 - 14:16:25 -
MichaelFiedler
Main
Main Web
Create New Topic
Index
Search
Changes
Notifications
RSS Feed
Statistics
Preferences
Webs
Main
Sandbox
TWiki
Български
Cesky
Dansk
Deutsch
English
Español
Français
Italiano
日本語
Nederlands
Polski
Português
Русский
Svenska
简体中文
簡體中文
Copyright � by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our
Terms of Use
Ideas, requests, problems regarding this site?
Send feedback