On Wed, Apr 16, 2008 at 08:51:03PM -0700, John Plocher wrote: > On the other hand, it is in the community's best interest for us all > to figure out how to effectively solve this problem rather than simply > self destructing because of the problem.
I fail to see how deferring a solution until adequate information is available to make a reasonable decision constitutes "self-destruction". Could you elaborate? > We *have to* figure out how to fill a repository with the "15,000 > debian things" without killing the projects, the ARCs, the Community > or OpenSolaris. I don't share your commitment to this goal, but I will express a requirement. When we finally awake from this horrifying nightmare, it needs to be quick and easy to pick up where we left off with architecturally sane, well-integrated consolidations. Whether they're packaged up using SVr4 or IPS makes no difference; the important thing is that we can jettison all the unreviewed, underreviewed, or exception-stuffed content at the source level. It's also important that this be possible at any time between now and then; i.e., anyone can escape for the cost of maintaining a fork. This suggests that the content in question simply be kept in its own consolidation that does not require ARC review to integrate. This consolidation should then deliver its output to a separate repository clearly segregated from the rest. Everyone's expectations will be very clear without needing a bunch of flags and taxons. In fact, while we're using Debian as a model, I'll even point out that this is analogous to their "non-free" packages, segregated and named in a way suggesting that one might be better off without them. Perhaps we could achieve the same result by putting these packages in a repository called "debian-like". If you really insist on a more clever solution, a single bit will do. There's even a standard that provides a good template for its implementation; see RFC 3514. Cost to the ARC: zero. Cost to the projects: zero. Cost the Community: trivial costs in repository management process. Cost to OpenSolaris: negative - provides major benefits. Seems like a winner, no? > Not at "time filed", but by the time the team comes for commitment. Which in virtually all these cases is the same thing, but yes, I stand corrected. > This is a threadbare rationalization - Indiana is a Prototype, and > is not defined well enough to present the ARC with a real > architecture - or maybe they have such an architecture, but they > are so busy implementing it that they don't have time to tell anyone > about it. Since they are not integrating it into any consolidation > (ON, SFW, X, JDS...), they can get away with this fiction. > > There is a double standard here, but it isn't what you think. Distros > like Nexenta, Belinix and Schillix did exactly what ips/pkg has done, > without any attempt at ARC interaction or exposure, and nobody thought > twice about things. But, when *we* attempt to do the same thing, we > get our shorts tied up in knots. Go Figure. Probably because if one doesn't like Nexenta's architectural choices, one can simply go back to an architecturally sane collection of software (the consolidations) and make one's own choices. If that collection were simply replaced by Nexenta, that choice is removed. Makes perfect sense to me. What is it about this that surprises you? -- Keith M Wesolowski "Sir, we're surrounded!" Fishworks "Excellent; we can attack in any direction!"
