Hi Bruce, On 08/24/09 18:07, Bruce Rothermal wrote: > 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. >
OK, then it can make sense but it should be in PSARC materials - the description how it will be used by some additional product. One additional thing - will that additional product be in /release repository or in some other repository? Best regards, Milan > 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 > > > ------------------------------------------------------------------------ > > > > Bruce Rothermal > Email: bruce.rothermal at sun.com > Skype: bruce.rothermal > Google Talk: bruce.rothermal at gmail.com > > > >
