[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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>&gt; </FONT>
>><BR><FONT SIZE=3D2>&gt; no way! why import a real-world obscenity into =
>>a virtual </FONT>
>><BR><FONT SIZE=3D2>&gt; arena where it is unnecessary?</FONT>
>><BR><FONT SIZE=3D2>&gt; </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: