It has already gone through /contrib and now management wants all the packages which we are going to use in our product to be /release level.
Bruce On Aug 24, 2009, at 9:09 AM, Milan Jurik wrote: > Hi, > > On 08/24/09 09:50, Garrett D'Amore wrote: >> Joep Vesseur wrote: >>> On 08/21/09 22:31, John Fischer wrote: >>> >>> >>>> This project proposes to integrate the Environment Modules within a >>>> Minor release of Solaris (i.e., Open Solaris). The environment >>>> modules >>>> provides an easy modification to a user's environment via TCL >>>> scripts. >>>> These scripts set various environmental variables such as PATH, >>>> MANPATH, >>>> etc. >>>> >>> >>> I'm not sure my remarks make any PSARC sense, but since there is no >>> rationale mentioned for integrating this, I'm inclined to ask >>> anyway: >>> >>> Does it really make sense to force people into being able to read/ >>> write TCL in order for them to configure their shell? I imagine >>> that most of the modulefile(4)s would be written by administrators >>> (how many of them speak TCL?), but users will have to debug/ >>> override >>> any settings they want to tweak. >>> >>> I'm just wondering why we pick a TCL-based configuration tool for >>> something like this. If the answer is Linux-compatibility, I think >>> there is enough precedent, whether I like it or not. Otherwise, I'm >>> not sure that we build a useful architecture here. >>> >>> Joep >>> >> >> I'm fairly confident that *except* in so far as we are integrating >> something which some sites or projects might already be using (and >> hence are offering it as a compatibility/familiarity tool), this >> case would not otherwise be ready for PSARC to vote on... I think >> we'd want to have a lot more scrutiny over a change intended to >> fundamentally alter the way user environments are managed. >> >> So, as a Linux familiarity tool (and I have to take the word of >> others here that this tool really is used by enough folks to make >> our time spent on this case worthwhile), I'll give it a +1. >> >> However, I'd have much more grave reservations about making this >> case a precedent setting case for the fundamental way user >> environments are managed (or that we recommend they be managed.) >> >> I still remain, at a fundamental level, unhappy that we have no way >> of distinguishing to our users, or to our ISV partners, which >> technologies we believe are fundamentally architecturally correct >> and "first class", and those technologies which we integrated >> simply to make us conform more closely to Linux (and which we might >> elect to steer users and ISVs away from.) But unfortunately at >> present we have no framework to provide this information to the >> people who need it most. >> > > There are several levels: > > 1) release repository with several levels of support for different > software in repository > > 2) contrib repository > > I tried to find this software in Debian popularity contest, but I > cannot identify package name in Debian (too much generic name). > > Why cannot non-obvious "Linux fam" cases go through contrib > repository at first, to see how many users they have? > > Best regards, > > Milan -------------- next part -------------- Bruce Rothermal Email: bruce.rothermal at sun.com Skype: bruce.rothermal Google Talk: bruce.rothermal at gmail.com
