Re: [Linuxcoe-devel] HP LinuxCOE versus Open Source LinuxCOE

[Bryan G. <bry...@hp...>]

Jeff,

It occurred to me this morning, that there might be some folks
confused between LinuxCOE (the service offering), and LinuxCOE (the toolset).
What we have opensourced is the latter.  Anyone could set up an
instance of the former (based on the latter) for a given environment.

> The umbrella project concept works for me. I'll try an ASCII art diagram
> to see if I'm visualizing it correctly:
> 
> LinuxCOE Project
> |__Open Souce LinuxCOE (sub-)Project
> |  |__System Designer Code
> |  |__Waystation Code
> |  |__User Documentation

This is the toolset portion.  Changes here should be shared back to
the SF development site.  Likewise with issues/feedback, etc.

> |
> |__HP Proprietary LinuxCOE Project (A.K.A. LinuxCOE Integration Project)
> |  |__HP Proprietary Modules Development
> |  |__HP Specific Documentation
> |
> |__HP Instance of LinuxCOE
>    |__Global Waystations
>    |__System Designer Instance
>    |__HP Proprietary Modules
>    |__Customized Documentation

These are parts of the service offering for a specific customer.  As with
using any other toolset, the configuration, development, and content would 
remain specific, and quite likely internal to that customer.

> For the latter two main sub-projects, think of OSLP as someone else's
> Open Source project that we want to modify for use in HP. The
> Integration sub-project would be responsible for downloading OSLP's
> code, creating add-ons that work with that code, and then providing the
> modified code/add-ons to the group that actually ran LinuxCOE as a
> service for the HP customer. It makes a lot more sense to me to think of
> it this way.

This is a good summary as well.  Of course the "Integration" sub-project
would be internal to any customer of the LinuxCOE (toolset) project.

> > I don't know that we can collapse all support functions onto SF.net.
> > I would expect our current SR process to remain, and there will still
> > be internal mailing lists/irc/...  
> 
> We need to be pretty clear on how LinuxCOE is supported. Using the above
> diagram, there should be SRs for HP proprietary stuff, but change
> requests to the Open Source code base should go through the SourceForge
> tools. I imagine that we'll probably do a bit of redirecting/educating
> the first few months to ensure that requests end up in the right place.
> However, I think it would be a disservice to our Open Source Community
> members to not post change requests to a place where they can see and
> comment on them.

Again, toolset support @ SF.net.  Service support within the given
environment.  FWIW, historically the user base of the LinuxCOE service
have given feedback regarding the service (mostly), and the core team
has submitted issues/enhancement requests for the toolset.  In essence,
the model doesn't really need to change very much (except for the core
team, and as Paul mentioned, the occasional proxy).

bryang