[cgl_discussion] linux-ha as a PoC for CCM.1 Cluster Communication Service
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.
*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
> > one Randy is maintaining for KJP which you push into LKML? (holding
> > breath)
> No. For several reasons.
> I do not think it is aligned with the goals of the CGL project. The
> 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
> well in the carrier grade space. However, bundling these changes into
> 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
> (Especially when I don't incentive to use it myself ;).
> Besides, the steep majority of patches that I've seen from this group
> 2.4 based. I do only 2.5+ work, and am not prepared to take the step
> to 2.4.
> I do not immediately have the bandwidth to develop, integrate, and
> (and port!) the plethora of features that CGL contains.
> I am also not going to launder code or promote code that I disagree
> or I find disgusting. If such a thing were to happen, it would be
> 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).
More information about the cgl_discussion