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


Reply via email to