I've not seen an answer to my questions/concerns, which I posted
elsewhere (on the alias with the case number so that it will go to the
case log.) The questions involve the concern about building Sun
software on top of this, and insisting on additional review (because its
no longer a familiarity case, but deserves first class review), the
appropriateness of Tcl (for a couple of reasons), and issues with
adequate interface specification (the modules file syntax and commands
needs to be part of the review.)
-- Garrett
Bruce Rothermal wrote:
> There has been numerous mentions about OpenSolaris vs. Solaris.next
> and /release and /contrib. That OpenSolaris belongs to the community
> whereas Solaris is controlled by Sun. I really don't much care if this
> package is in Solaris but I do need it in OpenSolaris. So from my
> experience I only know of this one path offered to get packages into
> OpenSolaris's /release repository and that is to go through a Solaris
> consolidation. If anybody knows of some other way I would like to hear
> it. So far all I'm hearing is a bunch of philosophying. Is there
> anything technically wrong or harmful about this package. I have a
> task assigned to port this package for a project to create a product
> which we intend to sell and make money for Sun. I don't see what the
> fuss is. It is a simple layered application which helps the user,
> should they want to use this, to manage some environment for a
> project. I don't see anything in this that makes it mandatory,
> compulsory or in any way changes the Solaris or OpenSolaris
> architecture. Nothing about Environment Modules is started
> automatically or done hidden.
>
> So please advise if there is a different process for getting this
> package into OpenSolaris /release repository or for that matter how
> this simple little application will be destroying the
> Solaris/OpenSolaris architecture?
>
> Bruce
>
>
> On Aug 25, 2009, at 1:23 AM, Milan Jurik wrote:
>
>> Hi Mark,
>>
>> Mark Martin p??e v po 24. 08. 2009 v 17:00 -0500:
>>> Nicolas Williams wrote:
>>>> On Mon, Aug 24, 2009 at 07:02:18PM +0200, Milan Jurik wrote:
>>>>
>>>>>> Another question that may arise is the architectural status of
>>>>>> /contrib
>>>>>> (e.g., can the ARC bless integrations into /contrib in some
>>>>>> manner that
>>>>>> confers, say, protection to filesystem namespace camping in
>>>>>> /contrib?
>>>>>> do interfaces in /contrib have to advertise stability attributes?
>>>>>> etcetera).
>>>>>>
>>>>>> IMO: Integrate it all, and let users sort it out (a paraphrase of a
>>>>>> Spanish inquisitor quote) (e.g., with a voting scheme). If an
>>>>>> i-team can't commit to interface stability, then make all public
>>>>>> interfaces Volatile, and mark the package as "toxic interface
>>>>>> stability", see if users still want it :)
>>>>>>
>>>>>>
>>>>>>
>>>>> And who will sustain such thing for the next 10+ years? ARC is
>>>>> looking
>>>>> at effectivness Sun Engineering resources. Pushing something to
>>>>> repository does not mean end of issue, it is the cheapiest thing.
>>>>>
>>>>
>>>>
>>> 1) Any comment or opinion regarding /contrib or /release or
>>> "OpenSolaris" will be based on an effort that has had little or no
>>> direct ARC interaction.
>>
>> That's the question. What's ARC responsibility? Only "API" between bits,
>> or also the whole product architecture? From my understanding there is
>> small problem - OpenSolaris distro is Sun thing (it's Sun decision what
>> will be there), but OpenSolaris project is community thing. As I wrote,
>> if ARC will be deciding about /contrib vs. /release, it will remain
>> Sun-centric (other distros can have and have other oppinions).
>>
>>> On the one hand, it IS the elephant. On the
>>> other hand, it's SMI's elephant.
>>
>> I agree, it's Sun elephant. But not only. "Sustaining" does not mean
>> only Sun support/bugfixing of Sun distro. It means also that all other
>> projects going to the selected consolidation will need to take care
>> about the integrated project. Mainly in case of SFW consolidation. And
>> such resources are not only Sun Engineering. But yes, it is mostly Sun
>> problem.
>>
>>> What *is* /contrib? I know what Sun's
>>> marketing says it is. Is that the only source of information with
>>> which
>>> to qualify it and appropriateness for considering it as an approach to
>>> integration and deployment? How much speculation need we endure here?
>>>
>>> 2) This has been brought up several times before. I don't see anything
>>> really happening here until there are dollars behind it, or some
>>> serious
>>> direction from SAC or other technical management. But maybe that's
>>> paint you're referring to in the subject?
>>>
>>
>> I think I have no more to add here.
>>
>>> If you're serious about this, and #2 notwithstanding, I've got an ARC
>>> case started a few weeks ago where I intended to review our stability
>>> taxonomy in the light of today's world with: OpenSolaris(tm) here
>>> today,
>>> Solaris.Next(tm) around the corner, efforts to grow a nascent porting
>>> community, these things called IPS repositories, other software
>>> repository ecosystems (Glassfish's update center, Netbean's update
>>> center, Eclipse's update center), etc.
>>> http://arc.opensolaris.org/caselog/LSARC/2009/316/
>>
>> I and serious? Never :-) Thank you for pointer. I will follow this case.
>>
>> Best regards,
>>
>> Milan
>>
>
>
>
> Bruce Rothermal
> Email: bruce.rothermal at sun.com
> Skype: bruce.rothermal
> Google Talk: bruce.rothermal at gmail.com
>
>
>
>
