[EMAIL PROTECTED] writes: > > Another perfectly valid way to look at this is that Perl is _forced_ > > to be part of the minimum install image _because_ it's used for > > important system components. > > > > That's still architectural. > > There is a distinction between the runtime environment and the code the > developer writes and maintains. As Darren has pointed out twice, the > Perl runtime is already part of ON. Why should a Perl developer have to > concern him/herself with architectural issues about the runtime?
He shouldn't. But for the same reason that he may need to consider (for example) the restrictions that Zones place on packaging, and how that affects his project, he may well have to wander outside the narrow confines of his project to do that. In any event, that's not the point. See below. > > Yes, those would have essentially the same sort of impact. As far as > > I know, there's no explicit policy or precedent here. > > If we're trying to make it easier for more people to develop > OpenSolaris, making rules about what languages can and can't be used > seems counterproductive. > > I happen to agree with Darren on the point that PSARC isn't the place to > make these decisions. Having a committe make a implementation decision > for a developer really isn't appropriate. However, if you're intent > upon having a PSARC precedent, I'll draft a case requiring all future > development in OpenSolaris to take place in Z80 assembly and COBOL. Huh? I think you've greatly misunderstood what I wrote, what PSARC does, and what I've suggested should happen here. What I wrote is that there is no precedent (as far as I know) for making such a restriction on implementors. If there is someone out there who has a good reason (such as minimization or patch reduction) to create such a rule, then such a rule is *certainly* something that the ARC would review before it would be put into place. I'm suggesting that interested parties should draw up suitable language for such a rule, and run it as an ARC case. PSARC would probably be a reasonable place to have it reviewed, as it's a platform issue. ARC reviews are open; anyone who is interested is invited to comment. By casting this as a (presumably pejorative) "committee decision," I think you're substantially misunderstanding how our development system actually works and disparaging the work of those who participate in the process. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
