[Oslc-Automation] Email formatting style and plain text (was: Re: [oslc-core] Request for review of OSLC Automation specification)

Steve K Speicher sspeiche at us.ibm.com
Wed Jun 13 09:17:33 EDT 2012


Not weighing in on the conversation or picking on certain individuals 
(just seeing this more and more), and wanted to point out what this HTML 
formatted email conversation looks like in plain text in the archive 
http://open-services.net/pipermail/oslc-automation_open-services.net/2012-June/000185.html

As important as these conversations are, it is important that we work to 
keep a good record of them in a form that can be understood in the archive 
and a broad class of email clients.

I recommend (for those Lotus Notes users and other similar tools) to reply 
with "Internet-style history" and leave some trail of who made which 
comments.  You can also customize some of the responses by going to Lotus 
Notes -> Preferences -> Mail -> Internet.

Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645

> From: David N Brauneis/Raleigh/IBM at IBMUS
> To: Pramod K Chandoria <pchandor at in.ibm.com>, 
> Cc: oslc-automation at open-services.net, oslc-core at open-services.net, 
oslc-
> automation-bounces at open-services.net, 
oslc-core-bounces at open-services.net
> Date: 06/04/2012 06:37 AM
> Subject: Re: [Oslc-Automation] [oslc-core] Request for review of OSLC 
> Automation specification
> Sent by: oslc-automation-bounces at open-services.net
> 
> Pramod, 
> 
> See further responses/thoughts in bold red. 
> 
> Regards,
> David
> ____________________________________________________
> David Brauneis
> STSM, Rational Software Delivery Automation Chief Architect
> email: brauneis at us.ibm.com | phone: 720-395-5659 | mobile: 919-656-0874 
> 
> 
> 
> From:        Pramod K Chandoria <pchandor at in.ibm.com> 
> To:        David N Brauneis/Raleigh/IBM at IBMUS 
> Cc:        Michael F Fiedler/Durham/IBM at IBMUS, oslc-automation at open-
> services.net, oslc-automation-bounces at open-services.net, oslc-core at open-
> services.net, oslc-core-bounces at open-services.net 
> Date:        06/04/2012 02:26 AM 
> Subject:        Re: [oslc-core] [Oslc-Automation] Request for review of 
OSLC
> Automation        specification 
> 
> 
> 
> Thanks David for the answers, 
> My answers inlined between <pchandor></pchandor>
> 
> -|- Pramod Chandoria 
> 
> 
> 
> From:        David N Brauneis <brauneis at us.ibm.com> 
> To:        Pramod K Chandoria/India/IBM at IBMIN 
> Cc:        Michael F Fiedler <fiedler at us.ibm.com>, oslc-automation at open-
> services.net, oslc-automation-bounces at open-services.net, oslc-core at open-
> services.net, oslc-core-bounces at open-services.net 
> Date:        06/03/2012 04:53 AM 
> Subject:        Re: [oslc-core] [Oslc-Automation] Request for review of 
OSLC
> Automation        specification 
> 
> 
> 
> 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: brauneis at us.ibm.com | phone: 720-395-5659 | mobile: 919-656-0874 
> 
> 
> 
> From:        Pramod K Chandoria <pchandor at in.ibm.com> 
> To:        Michael F Fiedler/Durham/IBM at IBMUS 
> Cc:        oslc-automation at open-services.net, 
oslc-core at open-services.net, 
> oslc-automation-bounces at open-services.net 
> Date:        06/02/2012 09:37 AM 
> Subject:        Re: [oslc-core] [Oslc-Automation] Request for review of 
OSLC
> Automation        specification 
> Sent by:        oslc-core-bounces at open-services.net 
> 
> 
> 
> 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).
> <pchandor>I have no big concern here</pchandor> 
> 
> 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?
> <pchandor>I think when a AutomationPlan represents a group of 
Automations 
> (like TestSuite in RQM, workflow in DevOps), it might make sense to call 

> them "complex" type. Consider a scenario like user is defining a 
workflow in
> RTC, that when a build automation is completed, wants to run a Test 
> Automation. When user will query automation from the automation provider 

> (RQM), It would definitely like automation plan of 'test' type be listed 
to 
> choose from. Do we think this should be defined in service providers 
name 
> space?. I think having a type in spec will provide client hint about 
what 
> type of  Automation plan it is.</pchandor> <dnb>I really think this is 
> unnecessary, it is by choosing the  automation plans from the provider 
where
> this "hint" of what the automation plan might do. I think that the type 
> would like end up being close to unique per automation provider which 
kind 
> of defeats the purpose. What about automation providers that can do some 

> generic automation work, would it then be up to the Automation Provider 
to 
> change and require the end user to define the type of automation it is 
from 
> a list of categories. I do not see what the gain for the consumer is 
here...
> If I ask RQM and it returns test, if I ask RTC and it returns build, and 
if 
> I ask RAF and it returns deployment (always in each of these cases) what 
is 
> the purpose?</dnb>
> 
> 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.
> <pchandor>Exactly you answered my question here. Probably specifying ( 
> queued, started, running, paused, complete) states would be sufficient 
> here.</pchandor> 
> 
> 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.
> <pchandor>If it's meaning is only for client to determine whether it was 

> successful or not,  then it should be of type of boolean? With type 
being 
> (anyType), what value we attain for the client. In that case client can 
also
> determine same from the verdict.</pchandor> <dnb>I think there might be 
a 
> couple of more verdict states (I was simplifying it for the purposes of 
> differentiating it from state - I think other possible verdicts might be 

> "successful with warnings" or even "canceled."</dnb> 
> 
> Regards, 
> 
___________________________________________________________________________ 

> 
> -|- Pramod K Chandoria 
> 
> Advisory Software Engineer 
> 
> IBM Rational, India Software Lab 
> 
> [image removed] 
> 
> 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 
> 
> [image removed] 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> From:        Michael F Fiedler <fiedler at us.ibm.com> 
> To:        oslc-automation at open-services.net, 
oslc-core at open-services.net 
> Date:        05/08/2012 07:49 PM 
> Subject:        [Oslc-Automation] Request for review of OSLC Automation  
 
> specification 
> Sent by:        oslc-automation-bounces at open-services.net 
> 
> 
> 
> 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
> fiedler at us.ibm.com
> 919-254-4170_______________________________________________
> Oslc-Automation mailing list
> Oslc-Automation at open-services.net
> 
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net

> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
> _______________________________________________
> Oslc-Automation mailing list
> Oslc-Automation at open-services.net
> 
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net






More information about the Oslc-Automation mailing list