S h i v writes:
> 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 there's a man page, then absolutely so. If there's no man page
describing it, then one of the following is true:
- It isn't described because it's an internal implementation
detail. You shouldn't attempt to rely on implementation
details unless you're also part of the project or
consolidation that manages that detail.
- It's an oversight in the documentation. These should be
rare, but do happen. File a bug.
Looking at artifacts of the implementation, though, isn't really the
right way to find supported interfaces (the man pages *are*), so the
start of your question is a bit odd.
> 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.
I don't know of any automated way to map objects that may merely be
implementation artifacts back into controlling documentation.
That just seems backwards, at least to me.
> > 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.
I have no architectural references that describe what this "network
based repository" means for any system (much less OpenSolaris), so I
don't think that's a question with a meaningful answer.
However, at a guess, sure; one could place the enforcement point for
architectural reviews, which is currently the consolidation
integration boundary, at the point of integration into the repository.
Note that architectural review isn't "special" here. It's just one of
a number of reviews -- design, code, test, legal, and others -- that
must take place before integration, and that are currently checked by
C-teams at consolidation integration time.
We're lacking any description of how repositories operate, though, so
that's all just conjecture. Feel free to make up your own rules. :-/
> 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.
A consolidation is defined as a set of source code that is normally
built at one time and delivered into the larger product (or products)
as a whole.
I don't think consolidations go away just because you're using a
different file server to hold the packages, or because the packages
end up in a different archive format. Someone still has to build the
bits, and that means the bits get built *somewhere* and have some
architectural boundaries.
It's plausible that a new repository and/or packaging system may cause
all of us to look for smaller consolidations or different ones, but
that seems to me like a very different question from the one you're
asking.
It's not a simple trade-off. As you make the consolidations smaller
(towards the limit of one consolidation == one project), you end up
forcing each project to export more and more Committed interfaces,
because the alternative is contracts.
One of the benefits of having a larger consolidation (that I think
some of the repository fans might be ignoring) is that private
interfaces become easy to use and develop. Some things are easier and
faster to do in ON than they would be with a sea of tiny
interdependent but independently-run projects.
> > 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
I still have no architectural documents that describe how that
repository works, so we're just going on guesswork for that future
direction.
I wish I could give you something solid to work with, but I can't.
When the folks who are working on such things decide that they're
ready to discuss the broader implications with the ARC, I think
that'll be great.
> 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.
I can't parse "no consolidation." To my understanding, it means that
we ship bits without compiling them at all. Is the repository just
source code? Is the kernel an interpreter? :-/
> 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.
Back up and give us a clear description of the architectural
boundaries of these entities that deliver into the repository, and how
they relate to each other, and _then_ someone might be able to come up
with a coherent answer.
I don't think that workable development practices just fall from the
sky. They have to be thought through and documented, and that's
what's missing here.
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
