Re: the problems with Debian
Going from what I saw with the Potato development, we have major "base" packages
that get updated multiple times, while at the same time, other packages that
rely on these base packages are also being developed. For every change to the
version of libc, almost every package needs to be checked, and recompiled
against the new version. It would make sense based on this, that if the core
components that the rest of the OS on are "frozen" before the rest of the
development begins, it would lead to shorter development cycles. How many of
you remember sendmail breaking several times because of library updates?
Dave Bristel
On 14 Sep 2000, Manoj Srivastava wrote:
> Date: 14 Sep 2000 11:09:13 -0500
> From: Manoj Srivastava <srivasta@debian.org>
> To: debian-devel@lists.debian.org
> Subject: Re: the problems with Debian
> Resent-Date: Thu, 14 Sep 2000 08:58:31 -0700
> Resent-From: debian-devel@lists.debian.org
>
> >>"David" == David Bristel <targon@targonia.com> writes:
>
> David> We have two very large problems with the Debian community
> David> right now in my opinion. The first is that it takes far too
> David> long to RELEASE anything.
>
> This is actively being worked upon. The package pool idea
> would help. subscribe to debian-pool for updates and discussion.
>
> David> And by the time it does, each developer of a package needs to
> David> make changes, over and over again to compensate for this. The
>
> Huh? Could you elaborate, please? We do have policy changes
> (FHS and LSB compliance are likely to cause package level changes),
> but we do try and keep changes that impact every package to a
> minimum.
>
> David> second is that Debian by it's design, has grown too large for
> David> a single, "We throw everything into the pot, and wait for
> David> everything to be cooked properly before anything can be done"
> David> If you let things "cook" for too long, the people you are
> David> doing all the work for will forget they ever wanted it and go
> David> somewhere else.
>
> Whom are we doing all the work for, then? I certainly am doing
> it for mysself. I am not going away. Really.
>
> David> My solution consists of doing releases of each "Category" of
> David> package. Starting with base. Once base is "ready" for
> David> release, you can go to doing both the GUI(XFree86), and the
> David> other categories that require NOTHING that is not in base.
> David> The next phase would be for the applications that require the
> David> things that came before. Note that once the previous phase is
> David> done, there will be no additional changes in that section,
> David> except bug fixes. If a major bug is found in a previous
> David> section, an emergency fix is called, and all things that
> David> require that earlier secion are checked against the new fix.
>
> This would make releases impossibly long. You'll probably
> never release a whole system that weay; by the time base is frozen,
> and fixed, you need to free each category, and some may need changes
> to base by that time (new modutils, for example), and we start all
> over.
>
> You think the current method is sluggish? The new method is
> going to be way worse. And you may well lose out on general system
> level integration and testing. If you try to retain that, the release
> process would strech well beyond what it is now.
>
> A far better method is the package pool effort.
>
> manoj
> --
> Girls are better looking in snowstorms. Archie Goodwin
> Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
> 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Reply to: