Re: Senseless Bickering and Overpoliticization
On Fri, 3 Sep 1999 10:19:57 +0200, Sarel J. Botha <sjb@dundee.lia.net> wrote:
>On Thu, Sep 02, 1999 at 10:05:22PM +0000, Zygo Blaxell wrote:
>> 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.
>
>And when level 3 stuff is released level 0 stuff is more than 6 months old
>again.
No, by the time level 3 stuff is released the level 0 stuff has gone
through one or two more release cycles. There would never be a current
stable level 0 release that is more than six months old.
Or perhaps you're saying that the stable level 3 stuff is based on a
six-month-old stable level 0, which is true, but given the complexity of
debugging through three independently-maintained levels of dependency (not
counting upstream!) I'm frankly amazed that Debian can do it as well
as they do in only a single year.
Note that at somewhere around level 1 in my proposed structure you have
a perfectly serviceable development system without graphics support
(perhaps it has an X server but no clients). You can start porting
packages to another architecture from here. You can read news and mail,
set up a firewall, install packages from the previous stable level 2
and higher releases, and so on.
Also note that it may be a condition of level 0 release that the previous
level 1 and higher releases must work well with it. In that case,
the end user can simply use the old level 1 stuff with a new level 0 core.
Right now, perfectly good, stable, useful packages, which are leaf-nodes
on the dependency tree, are not part of a stable Debian release, because
there's no way to add such a package to slink, and there's nowhere
else to put them except potato. For a year these packages simply
aren't available in a stable Debian release.
>IMHO it would be better to have a GNOME group _inside_ Debian that only worry
>about GNOME, they'll be able to provide the latest GNOME packages all the
>time, for stable even. At the moment everyone works alone on their GNOME
>packages so it's not as easy to have the latest GNOME packages for stable and
>unstable.
Well...then create logical groups within Debian. This seems to happen by
itself anyway, and aside from documenting the fact that it does happen,
I don't see any particular need to formalize it unless non-Debian entities
are involved. However there's still the problem of synchronization:
too much of it.
Right now Debian consists of 3-4K independently maintained packages
which are integrated on a single monolithic release cycle. If any one of
those packages has a critical bug, the entire distribution is delayed.
Now IMHO this is OK if the package is glibc, which nearly the entire
system depends on. It's less OK if the package is 'whois'.
Debian is supporting an increasing number of architecture ports and
nationalizations. In order to release a monolithic Debian distro, is it
necessary to make sure that everything works on an Icelandic Mac SE/30?
I don't like the idea of Debian arch ports lagging behind the i386 version
(I have two different non-i386 architectures at home) and I would imagine
that people whose first language isn't English would be similarly annoyed
if the internationalization support wasn't there.
On the other hand, we could get "i386 English Debian" stabilized, then
have a task force of non-English-speaking non-i386 developers add support
for the other machine and human languages while the English-speaking
i386 developers start work on the next unstable release. Of course
this can work both ways--I'd imagine that even Icelandic developers
create the occasional new package on their Mac SE/30, which would have
to be translated to English and other languages and ported to all the
architectures.
I can see why Japanese Debian people would get frustrated and form their
own "after-market distributions" (distributions consisting of packages
that replace the existing distribution's packages). If I had to deal
with an organization that had long release cycles and did not have high
regard for my priorities, I'd start from their stable releases and roll
my own distro too. I did that with Red H*t for four years.
>> 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.
>
>It's great to update like this, but IMHO I think you should at least get stuff
>like GNOME and X with Debian.
Again, this is just a matter of perspective. I don't propose that
an end user should have to get ten different CD's to make a complete
Debian system; the group (or groups) that makes CD's or sets up the
apt/sources.list for boot floppies should take care of physically putting
all the Debian pieces into one logical "place." However, these CD's
would be made of the combined output of several groups with varying
levels of independence from each other, each of which consists of a
workable subset of all Debian packages.
--
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: