RE: [alf-dev] The role of source control in ALF

[Mark Phippard <markp@xxxxxxxxxxxxxxx>]

Scott,

Thanks for replying.  I will take a closer look at the requirements, I had 
only scanned them in the past.

I didn't mean to imply that source control plays no role in ALF.  For 
example, I can see the source control system sending events to ALF, such 
as when files are committed, so that ALF can perhaps initiate a service 
flow of some kind. 

What I was getting at is an issue that the POC demo actually raises.  A 
lot of the tools and areas that we are talking about for ALF operate on 
source code.  Would we ever envision a "GET" request delivering the 
results via an SOA?  I do not even know how that could be done. 
WS-Attachments maybe?  This seems impractical, so it seems like either all 
of these services are going to need access to the same physical location, 
or these tools are going to still need their own point to point interface 
to the source control system in order to get the source code.

So perhaps my points were two-fold:

1)  Source control-related vocabularly probably needs to focus more on 
what types of events a source control system should raise.  Since this 
scenario obviously makes sense and can provide a lot of value.

2)  When trying to explain ALF to someone, maybe it would make sense to 
look for other areas to focus on other than source control?

Related question:

Would we envision a source control system being able to ask questiosn/seek 
approval via ALF?  For example someone wants to checkout or check-in some 
source code.  Could the source control system send a request to ALF to see 
if it was OK?  For example, maybe the related issue has not been approved 
yet or something like that.

Mark

alf-dev-bounces@xxxxxxxxxxx wrote on 03/07/2006 09:38:42 AM:

> I think you have to separate out a bit the use cases that are modeled in 
the
> POC and the long term possibilities integrating SCM and other tools. 
Issue
> tracking is probably the most obvious: SCM integrates with ITS tools to
> version and manage change packages/change palettes/change sets (insert 
your
> tool's nomenclature here) that address specific defects across multiple
> release branches. But for many of the other tools in the ALM suite, we 
think
> there are plenty of cases where objects need to be properly versioned 
and
> managed at the infrastructure level, and see SCM as fundamental to the
> success of ALF-enabled workbench. 
> 
> The POC though has really only modeled the most superficial SCM use 
cases,
> which I think reflects more urgent short-term priorities for the project 
and
> does not properly model the role of SCM and the SCM repository in the
> overall process flow. Richard Title here at AccuRev has submitted some 
cases
> to build out the story a bit (and attempted to map out some common
> vocabulary among several leading SCM tools)--these are still pending 
review
> from the requirements group--but I think these will be a start to better
> representing the role of SCM in the suite.
> 
> I believe Kelly has posted these cases on the ALF requirements 
site...take a
> look and see what you think. We'd welcome some additional feedback and 
agree
> wholeheartedly that the SCM needs some further attention in the ALF POC.
> 
> Best, Scott
> 
> 
> 
> 
> Scott McGrath | Senior Product Manager 
> AccuRev, Inc. | www.accurev.com
> 781.325.0652w | 617.834.2339m 
> 
> 
> -----Original Message-----
> From: alf-dev-bounces@xxxxxxxxxxx [mailto:alf-dev-bounces@xxxxxxxxxxx] 
On
> Behalf Of Mark Phippard
> Sent: Tuesday, March 07, 2006 9:15 AM
> To: ALF Developer Mailing List
> Subject: [alf-dev] The role of source control in ALF
> 
> Watching the POC demo and writing my web service for Subversion made me 
> really start to question the role of source control in ALF.  I am sure 
> that there will be cases where having it supported will be useful, and 
> having a service interface to a source control tool cannot hurt, but I 
> wonder how well it is really going to work in the real world.  I think 
the 
> whole concept of an SOA kind of falls apart if ALL information that 
needs 
> to be exchanged cannot be done via the service interface.  In the case 
of 
> source control tools, the information that needs to be exchanged is 
> ultimately the source itself.  Do you eventually envision defining a 
> vocabulary or whatever, where the source control service would actually 
> deliver the artifacts via the web service?  That seems like it would be 
> hard to do and probably be overly resource and network intensive.
> 
> If all you can do is send an instruction to a source control tool 
telling 
> it to get source to some folder accessible via the web service that is 
> going to be very limited in how you can deploy and build your solution 
and 
> service flows.  Take the POC demo as an example.  You are doing a GET of 

> the source code so that you can build it, test it and scan the source 
for 
> security bugs.  This only works in the POC demo because all of the 
> services have access to the same location.  How is ALF going to move 
> beyond that in the real world?  Are users going to have to have all of 
> their source-related services deployed on the same server?  It seems 
like 
> in a real world deployment you are going to wind up just using the 
> features that are built into OpenMake, or Ant or whatever build tool is 
> used to let it go get the source from the source repository and then 
build 
> it. 
> 
> Is there a trick up your sleeve that I am not aware of, or is this 
always 
> going to be a real issue?  If it is, then I think we need to start 
> defining alternate reasons why ALF is going to provide value.  The 
problem 
> with the POC demo is that there are probably hundreds of tools already 
out 
> there that do the same thing much easier.  The only parts of that demo 
> that you could not do with a simple Ant script are the parts related to 
> the issue tracker and even that could be done relatively easily if the 
> issue tracker had Ant integration.
> 
> Thanks
> 
> Mark
> 
> 
> 
> 
> 
> 
> _______________________________________________
> alf-dev mailing list
> alf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/alf-dev
> 
> 
_____________________________________________________________________________
> Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM 
Email 
> Security Management Services powered by MessageLabs. 
> 
_____________________________________________________________________________


_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs. 
_____________________________________________________________________________