[cgl_discussion] minutes of PoC concall

Rod.VanMeter at nokia.com Rod.VanMeter at nokia.com
Thu Nov 7 14:21:10 PST 2002

> -----Original Message-----
> From: ext Skip Ford [mailto:skip.ford at verizon.net]
> Sent: Thursday, November 07, 2002 12:46 PM
> To: cgl_discussion at osdl.org
> Subject: Re: [cgl_discussion] minutes of PoC concall
> Rod.VanMeter at nokia.com wrote:
> > Mika: By December 4, this should all be running smoothly.  New
> > developer will go up in a couple of weeks, so we should have FSes
> > defined by then.
> A list of FSes was posted to one of these lists lately, and I 
> have some
> questions.  First of all, I guess that list was a proposal only?

Yes, that list was a proposal only.  The first official set of
FSes will likely be pretty close to that.  Feel free to suggest
changes/additions if you think they're needed.

I'll repost Mika's list here for discussion.

> But more importantly, many of the items on the list seem to be listed
> with a different potential maintainer than the person/group that wrote
> the code (assuming we're talking about the same code that I've seen.)

Forget the whole notion of a maintainer of a Feature Set.
Projects (which implement part or all of one or more features)
and Patch Sets will have maintainers, but not FSes.

The maintainer of a PS will collect enough patches to make up
the contents of an FS.  There may be a relationship between the
PS maintainer and the feature/project maintainer, or there may not.

If you don't like the fact that Mr. X picked NGPT for his POSIX PS,
then start your own and use NPTL.

Ram's list of Patch Sets will include all PSes that meet the basic
criteria of a PS that I posted, and that can be reasonably mapped
to an FS.  We won't be in the business of endorsing a particular
implementation, but we will still define what features and feature
sets that CGL is interested in.  We will track the progress of the
ones we care about, and will beat the bushes for help when it looks
like things will fall through the cracks.  Beyond that, it will be 
much more laissez-faire on implementations.


More information about the cgl_discussion mailing list