On Fri, Mar 21, 2008 at 6:54 PM, James Carlson <james.d.carlson at sun.com>
wrote:
> S h i v writes:
> > 1. If I want to know the stability classification assigned to any
> > particular interface on the system (or if it is
> > unclassified/un-arced), is there a way to do it?
>
> I posted on this recently in another thread, but the short answer is
> that there are a lot of these legacy interfaces, and each one requires
> judgement when a stability level is needed.
>
My question probably didn't come across properly. It is not about a
person coming to ARC for the purpose of introducing a piece of
software into the system. It is more towards unearthing history
information that is already in the system.
If I login into a default installation of SX and have a look at the
files in /usr/lib, /usr/bin, /usr/include then, can I, the user of the
system recognize the stability classification of the files.
If yes, I want to write a tool which helps in doing a gap analysis
w.r.t SX as the standard reference. I have belenix in mind, but this
should be usable by any other distro as well.
Tooling is possible if the information exists in a mine-able fashion.
>
> > 2. Which are the consolidations/projects at opensolaris.org that require
> an ARC?
>
> That's an interesting question.
>
> The ARC process doesn't really work unless all projects are involved
> in it. It's not something that can be done effectively in a piecemeal
> fashion, or that can be "optional."
>
<snip>
>
> I'd say that all consolidations must have a requirement of
> architectural review before allowing integration.
>
With network based repository, don't consolidations become
increasingly less relevant ?
Going into the repository itself is integration I suppose.
<snip>
>
> > [3.1] Can any opensolaris community project come to ARC with the
> > intention of making use of the body of knowledge to unearth
> > architectural issues of the project work if the work is to go into the
> > system but not necessarily via a consolidation but as a stand-alone
> > tool or a tool that will sit in a network repository.
>
> What?
>
> I think you're trying to make a thinly-veiled comment about Indiana,
> but I'm really not sure what it is you're saying.
>
Not at all. Infact my question was more on a positive note. With
network based repositories I am not sure if consolidations is the best
route to take (except ON).
I am thinking of Belenix. I am also trying to see if tooling is
possible that might be usable by any distro including Indiana.
I would like to explore options to keep any distro aligned with
already ARCed softwares in SX if the distros choose to.
> Yes, a project can live "forever" on the periphery if that's what it
> wants to do. I don't think that's a good thing -- it's disinctly
> anti-social not to allow others to build on your work -- but I see no
> useful law against it.
>
I am not sure how this line of thought came about. A project not
delivering into a consolidation doesn't need to mean peripheral or not
ARC compliant or anti-social practices.
Current practice
project ---goes into---> consolidation ---goes into---> distro(SX)
Future direction
project ---goes into---> network repository
There is no consolidation involved and I do not see it as bad !
I believe the latter model that doesn't involve consolidation is
better scalable and maintaining the checks and balances regarding
ARCing is a process issue that can be addressed.
>
> > [3.2] When should a project decide that it is the right point to go to ARC?
>
> As above, earlier is better.
>
> I think you're trying to build a case against Indiana/OpenSolaris, and
> I just don't think it's going to work this way.
>
Not at all.
On the other hand I am looking at things in a much positive light and
I am exploring the possibility of a case for *any* distro based on
technologies from opensolaris.org to benefit from ARC.
-Shiv
