RE: the problems with Debian
I'm not going to respond on the issue of what's happened with KDE, but with my
own perceptions of what's been happening with Debian for the past two years. In
that time, I've gone from being semi-active with the Debian community, to
someone who watches, and has all but given up hope that the problems will be
addressed. As is the nature of most Americans, it seems to have infected almost
the entire Debian development team. The SYMPTOMS are what get looked at, not
the source of those symptoms.
We have two very large problems with the Debian community right now in my
opinion. The first is that it takes far too long to RELEASE anything. And by
the time it does, each developer of a package needs to make changes, over and
over again to compensate for this. The second is that Debian by it's design,
has grown too large for a single, "We throw everything into the pot, and wait
for everything to be cooked properly before anything can be done" If you let
things "cook" for too long, the people you are doing all the work for will
forget they ever wanted it and go somewhere else.
These can both be fixed in a fairly short ammount of time, but a restructuring
of how Debian is put together needs to be looked at. I've suggested it, and in
the past, there were a handful of people who agreed. Let's see if it gets any
more notice this time, and doesn't just fade away.
My solution consists of doing releases of each "Category" of package. Starting
with base. Once base is "ready" for release, you can go to doing both the
GUI(XFree86), and the other categories that require NOTHING that is not in base.
The next phase would be for the applications that require the things that came
before. Note that once the previous phase is done, there will be no additional
changes in that section, except bug fixes. If a major bug is found in a
previous section, an emergency fix is called, and all things that require that
earlier secion are checked against the new fix.
This is a way to LAYER the development, and will speed the release cycle that
takes well over a year to complete at the moment. It will also keep sudden libc
updates from breaking things, because the majority of the development work
doesn't come until libc has been made to work. It will save a HUGE ammount of
effort for those who are maintainers of X based packages over the course of
development. It would also give a sense of progress sooner(it shouldn't take
very long to get a working base working, compared to the entire distribution).
That's pretty much it. The same lines for package categories isn't being
touched, but the order in which changes are made during development will. The
next version can begin fairly quickly. Since base is done FIRST, the version of
base for the NEXT release can begin almost immediately. If it takes 6 months
from the conclusion of base development to release of the version of Debian it
was made for, that's 6 months that is available to work on the next version of
base. This will also add installation issues, as things like lilo(or a
replacement), installation scripts, and so on can be done. It also makes the
whole OS a bit more modular in it's development, so you ALWAYS know that what
you are developing on won't be broken.
On Tue, 12 Sep 2000, Seth Cohn wrote:
> Date: Tue, 12 Sep 2000 22:05:45 -0700 (PDT)
> From: Seth Cohn <email@example.com>
> To: erik <firstname.lastname@example.org>
> Cc: email@example.com, firstname.lastname@example.org
> Subject: Re: KDE2 - nice demolition job ...
> Resent-Date: Tue, 12 Sep 2000 21:51:51 -0700
> Resent-From: email@example.com
> On Mon, 11 Sep 2000, erik wrote:
> > I just can't keep my mouth shut about this any longer and the
> > unnecassary divisions (read demolitions) of KDE packages are the last
> > straw: I've been tracking the development of KDE2 for months and running
> > it quite successfully using "unofficial" debs (cheers to the folks at
> > kde.tdyc for bucking authority!)
> [and this drivel continues and continues for paragraphs....]
> You _do_ realize that the same guy who packaged it for kde.tdyc _is_ the
> same guy who is packaging it for Debian proper?
> > I think this is a pretty blatant example of the obvious failings of an
> > aging and inflexible beuracratic empire that cares more for its protocols
> > and levels of "authority"
> heh. Excuse, but as one future developer, I have to say that I see Debian
> as the group that cares the _most_ for doing things right. We may argue
> about _how_ to implement stuff, or even _why_ or _if_, but that's because
> the people involved care. Yes, there are petty bickers, and factions, and
> so on, but Debian is still the only distribution that exists on the scale
> it does and work well.
> > minutia and complaining about how there is too much to be done while
> > keeping "outsiders" waiting for months to even recieve acknowledgement of
> > reciept of application to voluteer (Oh, Yes, You too can help with
> > the Debian Project - just jump through these thirty complicated hoops and
> > apply to be a "developer" and wait around for a year or so and then if we
> > think you're cool ... garbage, why bother?).
> That's not true at all. So far, I'm in the new maintainer queue, and have
> a number of offers from sponsors to upload packages whenever they are
> ready. If you want to package something, at this point, yes, you should
> get into the queue, but finding a sponsor isn't very hard.
> Debian is about participation, and if you participate, you see results.
> > And try not to prove my point with condescending flames - its not
> > attractive.
> My flame isn't condescending. It's based on the fact that a) Ivan is
> doing a fine job of getting KDE re-packaged, give him some time.
> b) complaining about the new maintainer queue isn't productive, so go
> do something productive with that energy.
> and finally c) you really come off whiny. If you don't like the manual,
> help write a better one. If you don't like the way Debian deals with new
> users, help change it, by setting an example. File bug reports if
> nothing else. Etc.
> another happy Debian user,
> To UNSUBSCRIBE, email to firstname.lastname@example.org
> with a subject of "unsubscribe". Trouble? Contact email@example.com
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com