Re: Senseless Bickering and Overpoliticization
On Tue, 31 Aug 1999 17:13:25 -0700, Brent Fulgham <bfulgham@xpsystems.com> wrote:
>decision making in Debian.</FONT>
><BR><FONT SIZE=3D2>> </FONT>
><BR><FONT SIZE=3D2>> no way! why import a real-world obscenity into =
>a virtual </FONT>
><BR><FONT SIZE=3D2>> arena where it is unnecessary?</FONT>
><BR><FONT SIZE=3D2>> </FONT>
><BR><FONT SIZE=3D2>I am not suggesting that we should all get together =
>and vote for people</FONT>
Could the Debian archive be broken into logical sections along the
dependency tree? It would seem to me that if we want to have faster
release cycles, one way to do that is to do integration testing and QA
in smaller chunks. If we can keep the chunks at the "right" size
(not too big or too small), then we can continue to keep Debian scalable
as it expands.
Before people invest too much time reading this, I'd like to say that
I'd be _shocked_ if these ideas haven't already been discussed to
death before, possibly many times.
Supposing that Debian is broken up along its dependency graph. There
would be one group that does just the base distribution (packages that
are currently called "Essential": C libraries, perl-base, kernel images,
network configuration stuff...basically this is boot-floppies and the
base.tar.gz file), and they release a new stable miniature distribution
every N months, independent of all other groups within Debian. Call this
the "level 0" distribution.
Each time a new "level 0" distribution is released, the "level 1"
packages are built on top of it. These are packages that immediately
depend on the level 0 packages: X toolkits, applications that depend
on only the libraries in base, scripting languages and miscellaneous
libraries. They release M months after the "level 0" distribution
is released.
"level 2" would be packages based on the "level 1" stuff: more
complicated applications, window managers, standard utilities, complex
libraries which have more than two levels of dependency.
They release M months after the previous "level 1" release.
Have as many levels as are required to satisfy the dependency graph.
At "level T" (where T is the height of the package dependency tree)
we end up with CD images and a complete distribution.
At the higher levels, we can also split the archive by related packages,
so all the perl packages might have a release schedule distinct from the
Python packages. This gets really complicated in some cases, so it's
really something that has to be worked out by consensus by the maintainers
involved. Perhaps we are doing this already, we just don't really see it.
This means that it takes a year or so to get out a distribution, but we
can have several distributions in the pipeline, so there's a new distro
for end users every few months, instead of every year or so. "Yes, they're
all a year old, but that's OK, we provide _really_ smooth upgrades."
One drawback of this structure is that it spreads people very thinly,
and some packages depend on other parts of the system in ways that are
difficult to quantify, much less express. However, if we have a huge
number of people, this may be a better way to allocate them than to
throw a team of 500 people at a single release date.
Another drawback is that the package dependency graph is not necessarily
the best indication of what is more convenient to integrate and test.
>Debian has gone from being the best technical distribution, to being
Really? Which distribution is better than Debian, technically? I'd
really like to have my production Linux boxes running the best technical
Linux distribution, but currently they're just running Debian. ;-)
>quite stable but way way out of date. It is embarassing to see
>the reviews we get, comparing our 2.0.X kernel distro to the latest
>and greatest SuSe or similar. Reviewers having to go out and
>download GNOME from the web, etc., because they can't get a full
>set from Debian. This has to stop.
Now that we have apt, why do we have to have things like GNOME in the
distribution at all? It would seem to me that now the technology is
there that enables us to try to make Debian smaller, not larger.
Suppose the GNOME package maintainers split off from Debian, set up their
own Debian-like infrastructure, ran their own FTP site mirrors, etc,
set their own release schedule, and just built new packages on top of
Debian releases whenever they come out. I don't recall reading anything
that says that a Debian package maintainer cannot also be a member of
another organization, so the GNOME package maintainers could still be
Debian developers and maintain non-GNOME Debian packages as well.
The offspring groups would not have the economies of scale that the
parent Debian organization has, but they would lose the inefficiencies
that come with large size.
It would seem to me that if it's really advantageous to do this, people
could be doing it already. People do make things like kernel images
and new XFree86 releases available via apt-able URL's.
--
I don't speak for Corel, I just work for them. Use zygob@corel.ca for work,
zblaxell@furryterror.org for play, and zblaxell@feedme.hungrycats.org for PGP.
PGP fingerprint: 01 94 0F B3 46 B7 71 C3 D4 98 39 99 1B 34 45 A1
PGP public key: http://www.hungrycats.org/~zblaxell/pgp-public.txt
Reply to: