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

Re: Debian's problems



You also missed a very basic problem which would solve a HUGE ammount of
problems.  If we start the next release with a BASE system that complies with
what we want for the next release(glibc 2.1 for example).  Then all packages
that are beyond that would be a LOT easier to test for reliability.  We already
know what dependancies are needed for packages, so why not develop from the
ground up, with the base(which doesn't depend on anything except for other base
packages), then once that is READY, then the rest of the development can
continue without other packages which get upgraded from the previous release
needing 15 sub-releases during the development process.  It would also eliminate
a lot of the, "The following package breaks XXXXX".  While I am not a package
maintainer, I appreciate having to deal with this constant need to re-package
over and over to deal with other packages which break.  By developing the
distribution in phases, base-packages that depend only on base(phase 2)-packages
that only depend on other packages in base or phase 2(phase 3)-etc, you can make
it EASIER on the package maintainers, make it SAFER to install the next version,
and ensure that nothing gets missed.  This would also make sure that bash
doesn't suddenly get removed during an upgrade ;)


							Dave Bristel


On Sun, 12 Sep 1999, Joe Drew wrote:

> Date: Sun, 12 Sep 1999 23:00:19 -0400
> From: Joe Drew <hoserhead@woot.net>
> To: debian-devel@lists.debian.org
> Subject: Debian's problems
> Resent-Date: 13 Sep 1999 03:00:26 -0000
> Resent-From: debian-devel@lists.debian.org
> Resent-cc: recipient list not shown: ;
> 
> I've got some experience in leadership and what people need
> and don't need in order to get things done. I pride myself on
> my ability to simply put, get things done, period.
> 
> The problem with Debian is that it's currently got sort of a 
> mushy structure instead of having something concrete, "here 
> are our plans, now go forth and implement them, O our developers."
> This isn't from any one person, or any group of people; instead,
> it's because as things go on, anarchy ensues. It's a rule of the
> universe and it's a rule when you're dealing with people.
> 
> Now, there are some definite goals for potato, which I'm familiar
> with:
>  - FHS compliance
>  - Transition to perl 5.005
>  - Glibc 2.1+
>  - X 3.3.5
>  - Kernel 2.2
>  - And, as usual, updates
> 
> We've got everything but X and FHS behind us. 
> 
> Now, in order to run things properly, there are some things
> that everyone needs.
> 
> 1) People need direction. Very few are good at leading, but many
>    people are good at following directions.
> 2) People need limits. If you give someone a centimetre, they will
>    take it, and anything else they can.
> 3) People need to be able to say "We're done."
> 
> Right now, none of that's being done with Debian. It's not an
> insurmountable task, either, putting this into our structure.
> 
> Direction can be brought by our fearless leader, Wichert. Ruling
> by committee is a good thing, but for certain issues a leader
> has to put their foot down. Declare what we're doing, and how
> we're going to go about it.
> 
> Limits can be brought about by doing one thing, that everyone
> will bitch and moan about: /not/ forking off into unstable once
> potato freezes, and having every single maintainer of every single
> critical bug incessantly tortured about it until it is fixed, if
> it's possible to be fixed. Believe me, frozen will be finished
> quickly.
> 
> And finally, we're done. When X 3.3.5 is in there, and FHS has
> been achieved, we freeze, simple as that. Then, while we're frozen,
> bugs are hammered out, and hammered out, and hammered out.
> Then, when the final release-critical bug is gone, we go into
> super-deep-freeze for 2-3 weeks, while we see if any more bugs are
> lurking. Then we release, and we change frozen to unstable.
> 
> I really do think that it's a doable thing. It requires some
> strong leadership, and some talented individuals, but we've got
> that in spades. 
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> 


Reply to: