linuxcoe-devel — LinuxCOE development discussion

[Linuxcoe-devel] Developing on SourceForge

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

Here is the proposed development process:

-----
1. Each developer checks out a sandbox from CVS on SourceForge.
Instructions are found on 
    http://sourceforge.net/cvs/?group_id=144250 
under Developer CVS Access via SSH.

2. Developers make changes to the files and test them on their
development machine. When they are ready to test them on the testing
server (which matches the production environment as closely as
possible), they check them into CVS.

3. Files from CVS head-of-stream are checked out (perhaps by cron) to
the testing server. If possible, relevant regression tests should be
done to ensure the changes do not break anything else.

4. After the changes have been fully tested, the developer tags the
files as "stable". 

5. During the next release phase the stable files in the repository are
tagged with the version number of the release and that release is
exported and tarred for delivery through the SourceForge file server.
The tarball is then downloaded to the production server, extracted, and
installed in the relevant directories with that releases version number
(for example, /*/opt/SysDes/4.0/*). On the release date, symlinks to the
current version are updated to point to the new version.
-----

There will be another e-mail going out sometime tomorrow for the process
on critical bug fixes. Until then, let me know what you think about this
process.

Thanks,
Jeff

Re: [Linuxcoe-devel] Scope and Requirements

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

On Wed, 2005-07-27 at 10:18 -0700, ed fardos wrote:
> That's absolutely accurate in my opinion jeff; 
> regarding your question about scope between HP-COE
> and opensource-COE, i think it should be similar
> if not identical.

OSLP deliverables are going to be different than the HP LinuxCOE Project
(HPLP) deliverables because HPLP is a service and OSLP is not. That
makes it very difficult to have nearly identical scopes.

> Like Bryang said, LinuxCOE has a standing tradition
> to provide a GPL equivalent wherever we might have
> chosen a proprietary component.

And what exactly does that entail in terms of deliverables? OSLP is not
a service, so I'm not sure what we are providing when you say "a GPL
equivalent...". Do we customize deb/rpm packages for each distribution
and offer those for download?

I'll add a few more comments inline with my original post below, so keep
reading.

> --- "Shank, Jeffrey R." <js...@hp...> wrote:
> 
> > In this thread I'd like to discuss the scope and
> > requirements of the
> > Open Source LinuxCOE Project (OSLP). The HP LinuxCOE
> > system requirements
> > are to provide:
> > 
> >       * Network Installations
> >       * System Profiles

These two items are part of System Designer. As long as SysDes can be
configured to use public mirrors as waystations and a local DBMS for
storing system profiles, these deliverables are easily met in OSLP. The
most important thing to remember is that OSLP is not a service, but
rather the bits so that the user can run the service on their own
machine.

> >       * Patch Distribution Waystations and Tools
> >       * Package Distribution Waystations and Tools

A waystation is just a web/ftp server that offers content mirrored off
of other servers. Anyone can mirror a public distribution, so unless we
have some unique process or scripts that make it easier, this is out of
scope. However, the package/patch management tools that can be
pre-configured by SysDes could be considered in scope as part of the
SysDes deliverable.

> > We are also required to provide:
> > 
> >       * Configuration Tools
> >       * Security Tools
> >       * Event Detection Tools
> >       * Backup Tools

If I understand it correctly, we will provide these tools by means of
selecting existing GPL software and putting a special checkbox on the
SysDes screen under LinuxCOE Bundles. If we didn't offer these things,
users would still be able to select them by simply adding them to
Individual Packages box on Step 4 of SysDes. In other words, our
value-add is that we call them out as system lifecycle management tools.
Do we do more than this? Do we pre-configure them like we do the
package/patch management toolset? If not, this is it just a way to show
off SysDes's "bundle" feature.

Overall, we need to ensure that we do not look at OSLP as a service and
therefore remove service-based deliverables from the scope. We may need
to step back and define OSLP in less grandiose terms. As a service,
LinuxCOE provides provisioning and lifecycle management. As a tool set,
we have to define OSLP in terms of what code we uniquely provide. System
Designer is a huge chunk of that. Is there anything else?

Re: [Linuxcoe-devel] Home Page

[ed f. <edf...@ya...>]

that looks fantastic jeff, i didn't even know hp
had a template.. and @hp templates are out of the
question :).  Our oscon handouts will still have
the projects/linuxcoe url... the new template url
will be ideal when it's done..

thanks,
-craig


--- "Shank, Jeffrey R." <js...@hp...> wrote:

> Using HP's template for open source projects on
> SourceForge, I developed
> an initial home page for use at
> http://linuxcoe.sourceforge.net. The
> page isn't complete, but it is a whole lot better
> than a directory
> listing. :)
> 
> If you need to change anything, you can checkout the
> www module from
> cvs, update the page, check it back in, and tag it
> as 'stable'. I'll be
> making more changes on Tuesday so if you'd prefer to
> wait until then,
> e-mail your change requests to me and I'll update
> the page.
> 
> 
>
-------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux
> Migration Strategies
> from IBM. Find simple to follow Roadmaps,
> straightforward articles,
> informative Webcasts and more! Get everything you
> need to get up to
> speed, fast.
>
http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Linuxcoe-devel mailing list
> Lin...@li...
>
https://lists.sourceforge.net/lists/listinfo/linuxcoe-devel
> 



		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 

[Linuxcoe-devel] Home Page

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

Using HP's template for open source projects on SourceForge, I developed
an initial home page for use at http://linuxcoe.sourceforge.net. The
page isn't complete, but it is a whole lot better than a directory
listing. :)

If you need to change anything, you can checkout the www module from
cvs, update the page, check it back in, and tag it as 'stable'. I'll be
making more changes on Tuesday so if you'd prefer to wait until then,
e-mail your change requests to me and I'll update the page.

Re: [Linuxcoe-devel] Scope and Requirements

[ed f. <edf...@ya...>]

That's absolutely accurate in my opinion jeff; 
regarding your question about scope between HP-COE
and opensource-COE, i think it should be similar
if not identical.  The implementation will be
different for sure since HP-COE would and could
include proprietary software.  As far as priority
is concerned, the four OSLP deliverables are most
important and should be fleshed out immediately,
the rest of the scope will need to be fleshed out
with technologies as we progress.  

Like Bryang said, LinuxCOE has a standing tradition
to provide a GPL equivalent wherever we might have
chosen a proprietary component.

r,
-craigerl

--- "Shank, Jeffrey R." <js...@hp...> wrote:

> In this thread I'd like to discuss the scope and
> requirements of the
> Open Source LinuxCOE Project (OSLP). The HP LinuxCOE
> system requirements
> are to provide:
> 
>       * Network Installations
>       * System Profiles
>       * Patch Distribution Waystations and Tools
>       * Package Distribution Waystations and Tools
> 
> for multiple architectures (i386, ia64, x86_64,
> hppa) and multiple
> distributions (RHEL, Fedora Core, Novell/SuSE,
> Debian, Ubuntu).
> 
> We are also required to provide:
> 
>       * Configuration Tools
>       * Security Tools
>       * Event Detection Tools
>       * Backup Tools
> 
> How much of the original HP LinuxCOE scope will be
> part of the Open
> Source LinuxCOE Project (OSLP)? Are there any items
> not on this list
> that should be part of OSLP?
> 
> 
> 
> 
>
-------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux
> Migration Strategies
> from IBM. Find simple to follow Roadmaps,
> straightforward articles,
> informative Webcasts and more! Get everything you
> need to get up to
> speed, fast.
>
http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Linuxcoe-devel mailing list
> Lin...@li...
>
https://lists.sourceforge.net/lists/listinfo/linuxcoe-devel
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

[Cope, J. (O. Nashua) <Jos...@hp...>]

> There should be SRs for HP proprietary stuff, but change requests to=20
> the Open Source code base should go through the SourceForge tools.=20

Can we expect the average user to make the distinction between the=20
proprietary parts and the open source parts? For simplicity's sake,=20
I'm with Paul: a single point of contact inside HP would make the=20
end user's life easier.=20

   - Josh

(IBM ad likely follows. Hi, IBM!)

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.

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] Scope and Requirements

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

Jeff,

Set #1:
> In this thread I'd like to discuss the scope and requirements of the
> Open Source LinuxCOE Project (OSLP). The HP LinuxCOE system requirements
> are to provide:
> 
>       * Network Installations

Either a distinct item, or included in this is the retrofit ability

>       * System Profiles
>       * Patch Distribution Waystations and Tools
>       * Package Distribution Waystations and Tools
> 
> for multiple architectures (i386, ia64, x86_64, hppa) and multiple
> distributions (RHEL, Fedora Core, Novell/SuSE, Debian, Ubuntu).

Either of these enumerated lists can be expanded over time.  Key
requirement is the "multiple" phrasing.

Set #2:
> We are also required to provide:
> 
>       * Configuration Tools
>       * Security Tools
>       * Event Detection Tools
>       * Backup Tools

Only items 1, 2, and 4 are on the current list.

> How much of the original HP LinuxCOE scope will be part of the Open
> Source LinuxCOE Project (OSLP)? Are there any items not on this list
> that should be part of OSLP?

The minimum is Set #1, and if the current Patch/Package management
toolset is retained/enhanced, Set #2 (or even an expanded version)
is easy to implement and provide.

bryang

> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Linuxcoe-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxcoe-devel

[Linuxcoe-devel] Scope and Requirements

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

In this thread I'd like to discuss the scope and requirements of the
Open Source LinuxCOE Project (OSLP). The HP LinuxCOE system requirements
are to provide:

      * Network Installations
      * System Profiles
      * Patch Distribution Waystations and Tools
      * Package Distribution Waystations and Tools

for multiple architectures (i386, ia64, x86_64, hppa) and multiple
distributions (RHEL, Fedora Core, Novell/SuSE, Debian, Ubuntu).

We are also required to provide:

      * Configuration Tools
      * Security Tools
      * Event Detection Tools
      * Backup Tools

How much of the original HP LinuxCOE scope will be part of the Open
Source LinuxCOE Project (OSLP)? Are there any items not on this list
that should be part of OSLP?

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

[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

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

[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

[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

[Linuxcoe-devel] Software Engineering Methodology

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

With every new project comes the choice in how to run the project. We
want to run the Open Source LinuxCOE Project (OSLP) in such a way that
people from the Open Source Community can easily learn our methodology
and contribute.

There are many methodologies to choose from, but most fall into two
categories well known to most Open Source enthusiasts: the Cathedral or
the Bazaar.

http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/index.html

Cathedral development methodologies are described by the Wikipedia entry
on Open Source as:

"In the Cathedral, model development takes place in a centralized way.
Roles are clearly defined. Roles include people dedicated to designing
(the architects), people responsible for managing the project, and
people responsible for implementation. Traditional software engineering
follows the Cathedral model."

Most HP software engineering methodologies, such as HP
Methodology-Enhanced and the HP Global Method, are Cathedral style. We
can certainly adapt a Cathedral model to work for this project.

Alternatively, we can use the popular Bazaar model embraced by companies
such as Apache, Linux, and Perl. This model is characterized by many
traits (see attached PDF) including early and frequent releases, high
modularization, and a dynamic decision making structure. The advantage
of this model is that many members of the Open Source Community are
comfortable with this model and can adapt to it quickly.

Let's take an initial vote on whether we want a Cathedral or Bazaar
model. Afterwards, we can work on adapting the model to become our
methodology for the OSLP.

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