* James Carlson <james.d.carlson at sun.com> [2009-06-09 18:03]: > [Removed appliances-discuss because their mailman doesn't like me, and > I'm not bothering to join their list just for this one thread.] > > Stephen Hahn writes: > > * James Carlson <james.d.carlson at sun.com> [2009-06-09 13:38]: > > > The alternative seems bleak to me. It would mean that communities > > > would effectively be able to endorse only a single distributor's > > > (indeed a single vendor's) vision of what projects are valuable, and > > > would consign non-compliant projects and simple experiments to an > > > unnecessary purgatory elsewhere on the net. > [...] > > I do disagree with your last point, however: projects that don't want > > to work within a particular CG and whose leaders have no interest in > > persuading others of their merits via reasoned argument should be sent > > into the wilderness. (That's not this project or these leaders.) > > But getting back to my original point, and to make it a bit more > concrete: if a project team would like to experiment with some > packaging system other than IPS (or perhaps no packaging at all) or > would like to try solving the same problem that some other project is > already solving, should that result in exclusion?
Nope. > I don't think it should. These folks have come asking for endorsement > of their project, which means that they *are* engaging the community > leaders at the start. If they weren't doing so, they could hide out > on sourceforge indefinitely and spring a surprise later; there's no > actual requirement that anyone anywhere develops his design or code > using opensolaris.org facilities at *ANY* time prior to integration. True. > 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. > 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. > I'm very concerned that the policy you're describing sets the bar too > high and has a notably poor effect on experimental projects. It's as > if we've done our one big experiment and now we're choosing to pull > the ladder up behind us -- our own distribution experiment hasn't > integrated, and yet there can be no others. No, I'm not interested in stopping experimental work. > > > Thus, I'll reiterate my +1 for this project. I think it's a great > > > experiment, and deserves some real estate on the opensolaris.org web > > > site in order to do its work. That's all we're really discussing here > > > -- not whether this project will ever integrate anywhere, not whether > > > we're giving it Sun's imprimatur -- but just whether this community > > > should allow it to exist as an OpenSolaris Project, and I think it > > > should. > > > > I had thought that projects were supposed to produce something > > tangible; perhaps the current instantiation policy dropped that > > requirement. > > I can find no such requirement here: > > > http://www.opensolaris.org/os/community/ogb/policies/project-instantiation.txt > > or here: > > http://www.opensolaris.org/os/community/ogb/governance/ > > I don't recall "tangible" results ever being a condition. It's > possible, but I don't recall it. (Such a thing would probably rule > out at least the user groups.) It sounds like that requirement was struck from the policy. (The user groups are well known to be a hack to work around website limitations.) > In fact, that former link has this note in it: > > Requests for sponsorship are opportunities for constructive > engagement; they are not adversarial proceedings or formal reviews. > The objective of discussion of a proposal is to achieve consensus, > not to test or try the submittor(s). > > 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. > > If the goal is merely a separate, focused discussion, > > the Install CG can request the creation of > > install-jeos at opensolaris.org. The pkg(5) project is happy to see > > package dependency fixes, refactored package boundaries, and new > > metapackage recipes; anyone producing three non-trivial patches is > > granted commit rights. > > 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. > 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. > > 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, - that overlap makes the need for a distinct project that intends to influence that particular distribution unclear, and - that duplication of effort is more likely if discussions and proposals are not regularly reconciled. There are numerous ways to avoid that duplication of effort. I have proposed some; careful project leadership should also manage to do so. Perhaps other Install contributors have some comments? - Stephen -- sch at sun.com http://blogs.sun.com/sch/
