On Tue, Apr 15, 2008 at 04:56:58PM -0400, Brian Utterback wrote:
> Bart Smaalders wrote:
> >
> > Perhaps you could simply accept that we're going to have a networked
> > repository, rather than raising the same pointless issue on every
> > FOSS case that comes up. We simply cannot wait to begin integrating
> > more FOSS into Nevada until we switch packaging systems.
>
> Nobody says we have to wait until the repository is up and running. The
> real issue is that it is impossible to do the architectural review
> without knowing the characteristics and requirements of the repository.
> The need to put forward a case of the characteristics of the repository
> is the real bottle neck here. How can anybody comment on the
> architecture without knowing the new rules? It doesn't have to be
> implemented, just documented.
Garret objects to some FOSS being integrated now before the rules change
(if they do at all) with the advent of the vaunted repository.
I think the idea is that some such FOSS might have, I dunno, different
interface stability assignments, or something.
But the ARC and the i-teams can already do _that_ (haggle over interface
stability).
What the repository will necessarily change is the notion of package
meta-clusters (SUNWCXall, SUNWCall, SUNWCprog, SUNWCuser, ...).
And I don't see how that affects the discussion of this case, or zoo, or
unzoo, or unison, or whatever -- unless the ARC has that under its
charter and it just so happens that in most cases the question of
meta-clusters will get the given software is ignored because... the ARC
expects the c-team to do the right thing(?).
The ARC mostly does not look at package meta-clusters. When I did the
SQLite3 integration the cluster issue (i.e., what kind of installs get
what packages) came up only at c-team review time[*].
If the ARC needs to know what pkg cluster some FOSS ends up in, then let
the ARC ask for that information, else why is that coming up now?
> After all, if we know that there will be the 3 classes we referred to
> earlier, (core, layered, wild west) then we can classify each FOSS case
We can already do {core, layered, wild west} because we already have the
tools for that: interface taxonomy (and per-consolidation/product
integration rules, I suppose).
[*] SUNWsqlite3* ended up in various distinct meta-clusters
(SUNWsqlite3 -> SUNWCuser, SUNWsqlite3docs and SUNWsqlite3tcl in
SUNWCprog/all/Xall).
Nico
--
