Beyond Package Pools (Was: Re: A "progressive" distribution)
"J.H.M. Dassen (Ray)" wrote:
>
> On Wed, Mar 15, 2000 at 14:12:49 -0500, Jacob Kuntz wrote:
> > try this hypothetical release method out:
> >
> > there are two trees. let's call them devel and production. debian saavy
> > folks (maintainers) run devel. new packages are uploaded to devel where
> > they are tested extensivly. when a package has been in devel for more than
> > (for instance) two weeks, and it has no release critical and few important
> > bugs, it graduates into production.
> >
> > the production branch should always work.
>
> But it won't. This approach ignores the fact that "stability" is a property
> of a release as a whole (the set of packages and their interdependencies,
> ISOs, boot floppies and the upgrade path from the previous release) rather
> than the sum of the stability of individual packages.
>
> Ray
So, that's why the current scheme is correct? It obviously suffers from latency,
though it doesn't suffer from quality. It doesn't suffer from quality, because
releases are being "managed", in order for a package to get into stable it has
to go through extensive testing. That's in fact the main advantage of Debian.
Now, how do we combine this with responsiveness, and an organic distribution
like the FreeBSD? (in which there is rock-stable distro, a "working" distro,
and an unstable distro, three of which are constantly developing)
Here is the outline of a proposal which might do that:
1. Define subsystems within the debian system. One example is the X subsystem.
However, that's too big. The point here is that the current classification of
packages would be too coarse grained. I would suggest that, for instance,
X applications that support gnome and are IRC clients are one class while
console IRC applications are another class. A classification scheme as this
would
a) make browsing and finding of packages easier since it makes better
use of real world semantics
b) can be used to formalize things, it's just a DAG
2. Divide and conquer the release process. Define the dependencies and
interfaces of each subsystem with others. Then, reorganize the release
process as follows:
a) A Release Team is responsible for each subsystem. The Release Team does
not have to be comprised of developers of packages of that subsystem.
Release Team decides which packages "graduate" to working and then
to stable. Except that Release Teams may define other flavors of
distributions for their subsystem. [Here I assume that package pools
is working, and has three virtual distros called: stable, working,
unstable]
b) According to the number of packages (or the sum of "weights" of
packages) in that subsystem and the number of dependencies with other
subsystems (that's important), we give a weight to that subsystem.
According to some thresholds, small subystems are release-managed by
the smallest-weighted Team, closest up in the hierarchy. Some other
thresholds may be used to indicate the importance of the release in
that part of Debian.
c) Debian has some serious "glueware", config tools, and a complicated
package management. The policy for dealing with package management and
etc. seem to be quite effective at the moment. No need to fiddle with
that. However, the Debian specific software is represented also in the
regular release process, and since their weights would be great their
importance would have been shown faithfully. The use of these tools,
and policy is made even more comprehensive and documented extensively
for other developers.
d) There is a System Release Team which overlooks the activities of
subsystem Release Teams and coordinates them and guides them towards
some goals such as the release goals that Debian had in potato. The
Release Teams can have their own release policies and quality
considerations, however they would have to state their reasoning. The
System Release Team *doesn't* have absolute control over the Release
Teams, they just represent the overall concern for Debian.
3. Implement this new scheme. In the low level, tools such as debdiff and build
daemons will have significance. In the high level, package pools, release
management tools, and a web based status / modular organization tool
must be handled, probably the bug tracking system should interface with this
tool. Perhaps, the bigger release teams must have their own mailing
lists and other communication media, too. A developer should be able to find
other developers' contact information easily, and participate in subsystem
discussions... This is quite open-ended.
A point which might strike is the existence of task packages. Don't they
constitute, somewhat the required organization? The answer is both yes, and no.
The task packages in their natural extension could represent "a" part-of
hierarchy in Debian. However, they have overlapping parts. That's why they're
not strictly part-of hierarchies. Indeed, they represent differing "user views"
of the system. This might, and *must* be merged with a formal part-of and is-a
hierararchy, as it might cure some of the worse pains that await Debian in the
future (when we have 20.000+ packages!) I have an idea of these user views as
a way to formalize the Quality Assurance process, so that it can be modularized
in a way similar to the one I have suggested for the Release process.
Package pools, of course, is the main issue here. It is *the* mechanism which
lets developers create their own virtual distros, etc. This proposal lays out
a way to combine the flexibiliy of package pools with the quality provided
by the Debian releases.
Comments welcome,
Regards,
--
++++-+++-+++-++-++-++--+---+----+----- --- -- - -
+ Eray "eXa" Ozkural . . . . . .
+ CS, Bilkent University, Ankara ^ . o . .
| mail: erayo@cs.bilkent.edu.tr . ^ . .
Reply to: