linuxcoe-devel

[Linuxcoe-devel] HP LinuxCOE versus Open Source LinuxCOE

[Shank, J. R. <js...@hp...>]

One of the first threads I'd like to discuss is how we want to partition
HP LinuxCOE (the old LinuxCOE project) versus the LinuxCOE open source
project. There are a range of possibilities, two of which define
opposite ends of the spectrum.

1) We will continue doing all development internally using our present
processes and tools. When we are ready to release, we sanitize it for
external usage and dump it to CVS on SourceForge. When external people
contribute, we merge their contributions into the internal project and
continue the internal development process.

2) We move all development to the Open Source LinuxCOE Project (OSLP) on
SourceForge. Development that is still HP proprietary (such as certain
bundles) becomes a new internal project that functions as a
customization/integration project for the OSLP. The old LinuxCOE project
is migrated then sunset from HP.

I'll post my own opinion as a reply to this thread. I would really
appreciate hearing back from everyone on this list as soon as possible.
Hammering this issue out is the first and most vital step on the OSLP
road.

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

[Bryan G. <Bry...@HP...>]

My $0.02 worth ..

> 2) We move all development to the Open Source LinuxCOE Project (OSLP) on
> SourceForge. Development that is still HP proprietary (such as certain
> bundles) becomes a new internal project that functions as a
> customization/integration project for the OSLP. The old LinuxCOE project
> is migrated then sunset from HP.

This gets my vote.  However, we will still have a set of some
files to track what we mod (mostly as disaster recovery).

bryang

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

[Lee M. <lee...@hp...>]

> 2) We move all development to the Open Source LinuxCOE Project (OSLP) on
> SourceForge. Development that is still HP proprietary (such as certain
> bundles) becomes a new internal project that functions as a
> customization/integration project for the OSLP. The old LinuxCOE project
> is migrated then sunset from HP.

I think we have to do this.  Then we just maintain our 'addons', we can
still call it LinuxCOE internally, changing names would just confuse our
internal audience IMO.  But *WE* know it's really HPCOE, OSM, etc....

Lee

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

[Shank, J. R. <js...@hp...>]

On Tue, 2005-07-26 at 16:54 -0400, Lee Mayes wrote:
> I think we have to do this.  Then we just maintain our 'addons', we can
> still call it LinuxCOE internally, changing names would just confuse our
> internal audience IMO.  But *WE* know it's really HPCOE, OSM, etc....

D'oh! Replied directly to Lee instead of the list. Here is what I sent
directly to Lee:

"Agreed. Perhaps keep the LinuxCOE prefix and classify it mentally as
the LinuxCOE [Integration] Project. :)"

On the other hand, I want to make sure that we communicate with users
that LinuxCOE is being moved to SourceForge. Bug reports, enhancement
requests, and even e-mail about the non-proprietary parts of LinuxCOE
should be handled through our SourceForge tools. It might actually
result in more confusion to retain the LinuxCOE project name because HP
people will not be sure where to go for help or to contribute.
Sunsetting the LinuxCOE project and providing clear communication about
the new OSLP might be the best way to avoid confusion.

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

[Bryan G. <Bry...@HP...>]

Jeff,

> > I think we have to do this.  Then we just maintain our 'addons', we can
> > still call it LinuxCOE internally, changing names would just confuse our
> > internal audience IMO.  But *WE* know it's really HPCOE, OSM, etc....
> 
> "Agreed. Perhaps keep the LinuxCOE prefix and classify it mentally as
> the LinuxCOE [Integration] Project. :)"

I have always envisioned the LinuxCOE as an umbrella project, with the
first fileset to be delivered called SystemDesigner.

> On the other hand, I want to make sure that we communicate with users
> that LinuxCOE is being moved to SourceForge. Bug reports, enhancement
> requests, and even e-mail about the non-proprietary parts of LinuxCOE
> should be handled through our SourceForge tools. It might actually
> result in more confusion to retain the LinuxCOE project name because HP
> people will not be sure where to go for help or to contribute.
> Sunsetting the LinuxCOE project and providing clear communication about
> the new OSLP might be the best way to avoid confusion.

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/...  With regard to the move of the
codebase to SF, that should not be an issue, as almost nobody has
checked stuff in anyway (besides the core team).

bryang

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

[Shank, J. R. <js...@hp...>]

On Tue, 2005-07-26 at 15:28 -0600, Bryan Gartner wrote:
> I have always envisioned the LinuxCOE as an umbrella project, with the
> first fileset to be delivered called SystemDesigner.

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
|
|__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

Does this look good?

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.

> 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.

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

[Paul T. <pa...@hp...>]

On Tuesday 26 July 2005 02:15 pm, Shank, Jeffrey R. wrote:
> Bug reports, enhancement
> requests, and even e-mail about the non-proprietary parts of LinuxCOE
> should be handled through our SourceForge tools.

I disagree with this.  Our day-to-day (internal) users shouldn't need to know 
or care that we're moving CVS/development somewhere.  The long-established 
internal mechanisms for reporting bugs (email/irc/bts) should continue to 
work, and should be inside the firewall.  If we want to manually proxy the 
important bug reports over to the SF BTS we can.

My opinion,



 Paul.

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

[Shank, J. R. <js...@hp...>]

On Tue, 2005-07-26 at 14:51 -0700, Paul Telford wrote:
> I disagree with this.  Our day-to-day (internal) users shouldn't need to know 
> or care that we're moving CVS/development somewhere.  The long-established 
> internal mechanisms for reporting bugs (email/irc/bts) should continue to 
> work, and should be inside the firewall.  If we want to manually proxy the 
> important bug reports over to the SF BTS we can.

I think it is a question of ownership. When HP agreed to Open Source
LinuxCOE, they gave up ownership of LinuxCOE to the world. If we follow
the ASCII diagram that I created in another post, we would continue to
handle HP customer issues internally, but be willing (as you said) to
report customer problems to the OSLP team. This would be identical to
using someone else's software. A team in HP manages the instance and
fixes problems with that instance, but reports bugs on to the actual
developer. Following this model makes the support path much clearer for
those of us who are on both teams. It also supports your argument to not
confuse internal users. However, I think we should also empower the user
to file change requests directly with the OSLP team. The benefits are
that we have less proxying to do and we educate the customer about the
open source development model.

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

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

[Shank, J. R. <js...@hp...>]

Bryan,

I completely agree with your e-mail. A couple of points inline.

On Wed, 2005-07-27 at 08:07 -0600, Bryan Gartner wrote:
> > |
> > |__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.

So the revised diagram would combine these two subsets. This is, indeed,
how HP's model looks. The HP LinuxCOE team is responsible for both
developing add-ins and maintaining the service/instance. I modularized
them because the traditional model (in terms of the SDLC) is to have one
team responsible for making the tool meet the company's specific needs
and another team to actually run the service.

> 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).

This makes perfect sense. Let's make sure that when the original core
team submits issues/enhancement requests, they do so through the sf.net
bug tracker. This will ensure that all of the developers have visibility
of them.