[cgl_discussion] linux-ha as a PoC for CCM.1 Cluster Communication Service

Shureih, Tariq tariq.shureih at intel.com
Tue Jul 8 14:46:54 PDT 2003


I was kidding with the patch-set comment Pat, but it's good to know
where you stand on this issue.

But in general for CGL, your point is very valid and I will repeat the
recommendation to Julie and Mika to put this on the agenda for the next
requirements meeting (when Mika is back) to discuss the viability of
actually pulling some project maintainers of the top 10 or 20 P1
projects into the realm of CGL.

I'm interested in everyone's thoughts on this.


--
Tariq Shureih
 

*Opinions are my own and don't reflect those of my employer*


> -----Original Message-----
> From: Patrick Mochel [mailto:mochel at osdl.org]
> Sent: Tuesday, July 08, 2003 1:19 PM
> To: Shureih, Tariq
> Cc: Fleischer, Julie N; Zhu, Yi; cgl_discussion at osdl.org
> Subject: RE: [cgl_discussion] linux-ha as a PoC for CCM.1 Cluster
> Communication Service
> 
> 
> > Patrick, you're a Kernel hacker ;-)  How about a CGL patch set like
the
> > one Randy is maintaining for KJP which you push into LKML?  (holding
my
> > breath)
> 
> No. For several reasons.
> 
> I do not think it is aligned with the goals of the CGL project. The
target
> is not to maintain a version of the OS, it is to spell out what is
> required in a version of the OS. Right?
> 
> There is a necessity to do kernel-level development to get Linux to
run
> well in the carrier grade space. However, bundling these changes into
one
> tree does not guarantee that someone will use actually use it. I'm not
> interested in maintaining a tree that is not going to be used by
anyone.
> (Especially when I don't incentive to use it myself ;).
> 
> Besides, the steep majority of patches that I've seen from this group
are
> 2.4 based. I do only 2.5+ work, and am not prepared to take the step
back
> to 2.4.
> 
> I do not immediately have the bandwidth to develop, integrate, and
test
> (and port!) the plethora of features that CGL contains.
> 
> I am also not going to launder code or promote code that I disagree
with
> or I find disgusting. If such a thing were to happen, it would be
purely
> form an integration standpoint. I would forward obvious fixes and
> improvements upstream, but I am not going to stand behind something I
> vehemently dislike (e.g. SDEQ).
> 
> 
> 	-pat





More information about the cgl_discussion mailing list