[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-arc-discuss
Subject:    Re: [arc-discuss] A few questions regarding ARC process
From:       John Plocher <John.Plocher () Sun ! COM>
Date:       2008-03-21 17:37:27
Message-ID: 47E3F257.2030809 () Sun ! Com
[Download RAW message or body]

S h i v wrote:
>>  > 1. If I want to know the stability classification 
> 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.

Indirectly, yes

If the library in question has a man page, it is public, otherwise
it isn't.  The man page has an attributes section that will tell
you what kind of public:  Volatile, Uncommitted or Committed.



>>  > 2. Which are the consolidations/projects at opensolaris.org that require an ARC?
>> Jim Carlson wrote: 
>>  I'd say that all consolidations must have a requirement of
>>  architectural review before allowing integration.


+1

> 
> With network based repository, don't consolidations become
> increasingly less relevant ?
> Going into the repository itself is integration I suppose.

The definition of Consolidation is "a component or collection
of components that are developed, maintained and delivered as
a self consistent unit".  This usually means a single source
tree that is compiled together, packaged up and delivered to
Release Engineering (aka a repository) as a tagged set of
sysv packages.

The SFW consolidation only makes sense in a repository style
world if you presume that the components in it will evolve at
a rate dictated by the release schedule of the consolidation
itself, and that there will be no pressure to have the
subcomponents have a stand-alone life of their own.

I think that that presumption for SFW is false, which leads to:

In a repository world, it makes sense for each FOSS component
to be its own consolidation - apachehttp, tomcat, php, mysql,
firefox... each is built and maintained as a unit, and consumers
will want to download/install/use them at that level of
granularity.

In the OS.o world, each Project has a source repository, but
there is no connection from it to a "build system" that produces
binaries or packages out of it, and there is no connection from
it to a publishing repository.  If we had those pieces, we would
be able to treat "special" OS.o Projects as consolidations that
would automatically feed into the repository system...


> 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'm not sure where youare going here - do my comments above change
your perceptions?

> 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 !

If we can define "Project" as "Consolidation", then this still is true.
The ON case is simply one where a single Project under a CG is used as
the gate for their canonical source tree - other projects in the CG are
simply development environments that will feed into a gate in the future.
In a well functioning world, there might even be several gates in ON:

   ON Community
       Nevada Project         (a minor release branch)
       Nevada Update1 Project (a micro branch off of Nevada)
       Indiana Project        (a major release branch)

This gives

   project -> ON Project Nevada  -> network repository
   project -> ON Project Nevada Update1  -> network repository
   project -> ON Project Indiana -> network repository

as well as

   yourproject -> network repository

and for distro makers

   network repository -> distro(SX)
   network repository -> distro(belenix)
     ...

   -John
_______________________________________________
arc-discuss mailing list
arc-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/arc-discuss
[prev in list] [next in list] [prev in thread] [next in thread]