Pramod, I have a couple of thoughts on what you have proposed, I have added them inline in bold red.
Regards, David ____________________________________________________ David Brauneis STSM, Rational Software Delivery Automation Chief Architect email: [email protected] | phone: 720-395-5659 | mobile: 919-656-0874 From: Pramod K Chandoria <[email protected]> To: Michael F Fiedler/Durham/IBM@IBMUS Cc: [email protected], [email protected], [email protected] Date: 06/02/2012 09:37 AM Subject: Re: [oslc-core] [Oslc-Automation] Request for review of OSLC Automation specification Sent by: [email protected] I have few comments as mentioned below. Automation plan: Can we just call it Automation. Do we gain any meaning with plan. I think that the whole topic of the working group is automation and there are many things associated with it, I like keeping it as an automation plan and have already started to use that terminology with customers (and it seems to resonate). Automation plan: We don't have oslc_auto:automationType attribute. Without this we can't distinguish whether Automation is for build, test, deployment, cloud etc.. I think this needs to be typed. I actually do not agree with an approach that types the automation, there are some automation plans that might perform one or more of those different types as a part of the workflow (think a continuous integration or continuous delivery product - i.e., DevOps)... How would you characterize those? Also, some automation providers will exist that can support more than one type of automation and do not need them to be separated. What do we gain by forcing this? Automaton Request: oslc_auto:state - Probably it's value can be defined by specification, rather loosely relying on the provider. This will allows clients to write more predictable code rather writing specific code to each provider. I think verdict domain can be different for different provider but state of the Automation Request can be guided by specification across all providers. I think is needed because most automation providers will have the concepts of queued, started, running, paused, complete, etc. AutomationResult: oslc_auto:verdict is used for end result's verdict, oslc_auto:state - I am not sure why this property is mandatory when verdict is already available. In RQM there is only one field for verdict, there is no other state for result. I am thinking this should not be one-many but zero-many property. I thought this meant whether or not the automation executed successfully or failed. Regards, ___________________________________________________________________________ -|- Pramod K Chandoria Advisory Software Engineer IBM Rational, India Software Lab Bangalore, India | +91-80-417-77045 | +91 99805 68253 What's new in 4.0 RC0 | Ask Question in forum | Online Help | Download RQM 4.0 RC0 From: Michael F Fiedler <[email protected]> To: [email protected], [email protected] Date: 05/08/2012 07:49 PM Subject: [Oslc-Automation] Request for review of OSLC Automation specification Sent by: [email protected] The Automation workgroup continues to make progress on the specification and is working to move towards convergence with several early implementations beginning now. The workgroup would like to invite you to review the current draft [1] of the specification. All comments are welcome. We would especially be interested in feedback from Core members and Automation members who have not been in attendance lately. [1] - http://open-services.net/bin/view/Main/AutoSpecificationV2 Regards, Mike Michael Fiedler IBM Rational Software [email protected] 919-254-4170_______________________________________________ Oslc-Automation mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-automation_open-services.net _______________________________________________ Oslc-Core mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-core_open-services.net
