Re: Senseless Bickering and Overpoliticization
On Thu, 02 Sep 1999 22:05:22 GMT, Zygo Blaxell <e4k3l9lb@umail.corel.com> wrote:
>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>
Ack, where did _that_ mess come from? Serves me right for posting it
from a potato system, and for ignoring warning messages from nvi. ;-)
That _should_ have read:
>On Tue, 31 Aug 1999 17:13:25 -0700, Brent Fulgham <bfulgham@xpsystems.com> wrote:
>>If we are not willing to make decisions about when a release is
>>going to happen and then create strictures that encourage people
>>to do so, we will have longer and longer cycles between releases.
>>
>>Perhaps we should just do away with the whole concept of releases,
>>as it is not really meaningful. I have been running on unstable
>>for years, and aside from the occassional perl upgrade or whatnot
>>things are fine. Why not just say, our distribution is our
>>unstable archive. Every so ofter we copy it over to a new archive
>>and give it a release name. We could make such a "copy" prior to
>>landing some major horkage (like the great X reorg or the Perl update)
>>and continue.
The remainder of the text is mine with Brent quoted. If you read the
previous message, you don't need to read any of this again.
>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
>
>
>--
>To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
>with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
--
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: