Stephen Hahn writes:
> * James Carlson <james.d.carlson at sun.com> [2009-06-09 18:03]:
> > And in very broad terms, what they're describing is fairly obviously
> > of interest to those interested in install-related technologies. In
> > order to _start_ work on a project, that sounds entirely sufficient to
> > justify endorsement.
>
> I think we start to part ways here; I don't think that a CG needs to
> allow an infinite field full of angrily-filled clubhouses, but should
> in fact be trying to coordinate those efforts to some degree.
Infinite seems a bit overwrought.
Should that coordination among clubhouses occur before we supply the
project teams with nails and paint, or can it occur after?
I think it absolutely must occur later, as it obviously at least takes
time to build up some anger, besides the fact that not all or even
"many" conflicts are discovered or could possibly _be_ discovered at
the git-go.
So, I think that's a straw man. There is no "infinite field," and the
coordination is an on-going task, not a one-time checkpoint.
> > What more of "merits" would need to be disclosed before even getting a
> > project web site up and running? How much detailed planning overhead
> > should a project proposal have to cross the bar? And can't a
> > community group later yank an endorsement if it turns out that the
> > project team _isn't_ engaging the community or delivering something of
> > value?
>
> All valid questions. My point is that a CG can set the bar, so that
> it avoids the need to revoke all but the most unusual of its sponsored
> projects. If the Install CG CC's say "go", then that's great, but I
> don't think experimental projects should expect homogeneous treatment
> across all CGs.
So ... is the Install Community in particular one of the lesser or
greater CGs?
> > I believe that text was actually intended to cover *exactly* the issue
> > we're discussing. If I recall correctly, it was added [by John
> > Plocher?] to clarify the wide-open nature of OpenSolaris.
> >
> > Sponsorship isn't a project review and isn't intended to be one.
>
> One constructive outcome would be to suggest other possible means of
> collaboration.
Sure. But (somewhat surprisingly) as one of the core contributors
here, I'd be just as happy to hear that they get a web site and
mailing list where they can do their experiment in peace and come back
for more when they're good and ready.
> > What if someone wanted to do the same thing but outside the confines
> > of the pkg(5) project? Must the Install Community reject such a
> > proposal?
>
> They are welcome to do so, and the Install CG should admit them, as it
> has already done with the Conary exploration.
OK. So the objection is that since (per the proposal) it _is_ based
on pkg(5) _and_ (although it's not as clear to me right now) it could
possibly be overlapping some existing project, then that's not good?
I'm trying to get at the nut of this concern. I feel like I haven't
quite found it yet.
> > I don't think it ought to be rejected. I think OpenSolaris ought to
> > encourage experimentation like that -- even if it goes against a more
> > "established" project. If there are overlaps, it seems entirely
> > reasonable that a community group would demand a clarification on the
> > project team's web page ("Not affliated with Snyder's of Hanover"),
> > but withholding endorsement seems too severe.
>
> I think that your position has some gaps around projects that fail to
> live up to their commitments; in particular, I read it as "admit
> everything and sort it out later", without any consideration of the
> costs of that later sort. Even inactivity after some initial flurry
> has a cost to the CG. That aspect can be another discussion, but
> motivates me, in this one.
Lots of projects fail even after an auspicious beginning and even if
they're staffed by Sun-paid employees.
And, yes, project failure (for whatever reason) is usually expensive.
Particularly so if it occurs _later_ rather than _sooner_.
But since when has a concern about a proposed new project failing been
a reason to stop it from being endorsed by a CG? And why in
particular would someone judge this one as more likely to fail? Is it
merely because it appears to overlap some territory claimed by another
project?
I still think this is yet another way of saying that exploratory
projects are unwelcome, and I disagree with that position. Inviting
them to participate if they want in an established project is
certainly fair, but doesn't sound to me like sufficient cause to say
that they should *not* be given the endorsement they are seeking.
> > > Maybe it would be more clear if the JeOS proposers identified which
> > > distributions they hope to influence?
> >
> > Yes, that'd be interesting to know, if they indeed even know this now
> > themselves. It should probably be in project proposals, although it
> > isn't part of the current process.
> >
> > What if the answer is that it's intended to be a new distribution, or
> > that none has yet been identified? Is that grounds for exclusion?
> > What are we fishing for?
>
> I'm not fishing. I had thought I was fairly clear:
>
> - the proposal overlaps with work for pkg(5) and for Caiman, for the
> using-the-OpenSolaris-mark distribution,
If it's a trademark issue, then that sounds like a fair complaint.
If it's merely that they're doing something with pkg(5) and/or with
Caiman that those teams don't necessarily agree with, then I think
we're getting into the sort of project review that we're _not_
supposed to be doing.
> - that overlap makes the need for a distinct project that intends to
> influence that particular distribution unclear, and
I don't think I agree with that. They're clearly influenced to pursue
a particular model -- the JeOS model in Linux. That's not necessarily
what any other group is doing, and having a space to discuss that
seems quite reasonable.
Maybe the result of that discussion is something that is entirely
identical to what Caiman will deliver. Or maybe it's disjoint. Maybe
it's usable. Maybe it's just an experiment that gets tossed.
I don't think we know those things yet, and I don't think the
community group should *force* people to work together by denying
project requests.
> - that duplication of effort is more likely if discussions and
> proposals are not regularly reconciled.
Sure. So what? It's patently obvious that we are no longer building
a single system -- at least not within the confines of OpenSolaris.
And the fact that the project would be sponsored by this community
provides at least a forum for those discussions.
> There are numerous ways to avoid that duplication of effort. I have
> proposed some; careful project leadership should also manage to do so.
I don't think that duplication of effort is necessarily something that
should factor in here. A simple notice to the project team is more
than sufficient and (provided that they don't withdraw on their own)
should have nothing whatsoever to do with endorsement.
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
