also sprach Joel Baker <lucifer@lightbearer.com> [2002.02.15.2228 +0100]:
> * Why does Debian take so long to release?
>
> To be blunt: because we use goal-oriented releases, have almost no form of
> release schedule to abide by, and we allow mushrooming/goal-creep to run
> pretty much unchecked. These are all technical and social choices - but
> they have significant technical implications, which tend to amplify each
> other when combined.
quite well coined. however, i ask whether that's necessary. i am (and
others are) noticing feature-bloat in debian. obviously, 8000+
packages is something to be proud of, but the fact that we can't get
our act together to get RC bugs out of the way is kind of sad.
everyone wants to package software and noone wants to fix bugs. of
course, we can't force anyone, but if all that's left to do are
release-critical bugs, then it shouldn't be too difficult to set
a release date just to put a little pressure on those people that
care. i've also done management of software releases and have
concluded not only once that a combination of time pressure and actual
enthusiasm for a project can yield wonders.
for my part, i surely intend to participate in the party this weekend.
moreover, i have three weeks off, which aren't exactly free time, but
during which i'll be able to set a lot of time aside for debian. i'd
personally hate to see woody not out by the end of march. and i do
believe that it's doable.
but there's surely a point - we all kinda love to talk and discuss
even though it's quite obvious that this time 'round we need action
rather than words. i'll stick off the lists and invest time in RC bugs
instead. i'd ask everyone to consider doing the same. let's get woody
out just so that we can go back to discussing all the issues we love
to talk about.
> * Why does it *matter* that Debian takes so long to release?
>
> Perhaps it doesn't. It depends on what your goals for Debian are.
i actually agree. who cares? i don't see debian as a competitor to
anything but maybe slackware (in the linux sector that is). people
come to debian for what it is - the purest linux you can find, which
also just sticks to a cool policy and has apt. people bitch about old
software, but they fail to realize that potato is one of the best
operating systems out there - for productive use, and especially for
servers. it's micro$oft and others who have instilled the need for
everyone to stay up to date. i know folks that still use wordperfect
in dos for all text processing, and they are happy with it. it's fast
(one a 486) and it does what it needs. noone needs the crap that gui
software provides these days. noone needs the newest patches that ship
with every expensive windoze release.
noone forces people to stick with apt and .deb. noone forces people to
apt-get the source.
my real criticism on the project now is feature bloat and the belief
that debian really should re-establish its roots firmly before trying
to package everything that runs. i love the incredible choice that
8000+ packages give you, but i also find myself just not using
anything but the 100 packages i've always used simply because it's too
much. debian's impossible to grasp in terms of available packages, and
i am more intimidated by the volume presented in tools like dselect
rather than encouraged and proud.
> If your goal is to produce a collection of software that the
> developers have gotton to work together, and leave it sitting on
> a shelf - it isn't a problem at all. However, at least according to
> the Social Contract, that isn't what our goal is. Point 4 makes it
> quite clear that the *users* are our first priority - even above
> 'free software'. Our users are not served well by having release
> dates longer than the life-cycle of some of the software that we
> package.
that's a very valid point. however, debian's also about quality.
rushing to the next release will almost incurably affect quality, and
that's unacceptable. but we are faced by the problem of being built
upon the enthusiasm of volunteers, who also have to earn their way
through life in a regular job. how could one get people to see debian,
it's quality, and the release ahead as a duty, but without any
negative impact on the enthusiasm and belief that keeps most of us
going?
> * How do we avoid putting out buggy releases, while going faster?
>
> It is, honestly, fairly simple, if not terribly nice to contemplate. If
> a package has RC bugs, it doesn't get released. That's true already. But
> the release goal shouldn't be "No RC bugs" - because *a release is already
> defined to have no RC bugs* - any package with one didn't make it in. The
> release triggers need to shift to time-based triggers as the primary cause,
> in which we release whatever we have that *is* stable, or we admit that we
> just haven't gotton anything useful done, pack up our toys, and go home.
a system without base-passwd is not usable. RC packages cannot be
ommitted, and they won't be released with bugs in them.
i think that we should, at least for now, form a group of people who
stand by what they say, who are willing to put time and work into the
release, and who'll simply get control over all packages in the pool.
surfing the BTS makes it obvious that there are way too many
maintainers who don't care enough anymore, and given that "debian
developer" is a status rather than a responsibility (at least in the
eyes of the public), it's frightening to see the growth in population
in developer land.
i am sure that forming such a task force, which will supersume control
over the debian project, overriding privileges of other maintainers in
doing so, is not in accordance with the policy or the philosophy or
both, but i would also like to throw out the argument that even
a policy has to evolve with time, and even a new release may mark
a giant step in this evolution, asking for a policy change.
> Seriously, however - one of the things I have noticed is that the RC bugs
> seem to creep in largely during the periods of "code fast, code hard, we'll
> debug it during the release testing phase" - meaning that when the time for
> that phase comes, we have dozens of RC bugs in core packages that, to be
> perhaps *too* blunt, should never have existed for more than a few days.
isn't that always the case? it's been very much a problem in many
projects that i have worked with/for
> If we are not capable of maintaining our base system between releases
> without adding so many bugs that we can't *do* a release, we have a very
> serious underlying problem in how we deal with that base of software, which
> mere release management cannot deal with directly - that's an issue with
> the development process itself. All the release process can do is put some
> boundaries on it, and make it clear when the development process needs to
> change because it isn't working.
exactly. so we filter. those people that care and those that can't
persuasively argue so. and persuasion involves doing.
> * How do we avoid running out of toy names?
>
> Make Pixar do a new movie with more characters.
monsters inc.
heck, that's the most trivial thing in the world. for all i care, we
can name debian by colours or countries or cities or planets or seas
or chemicals or groups-of-the-sixties or this or that. it *doesn't*
matter. i'd even vote for a change away from toy names to something
cooler (like cities or groups-of-the-sixties).
> * How do we know when we've done a major-version release?
>
> This is a difficult question; how do we know *now*, really? It seems to
> mostly be involved with changes to the fundamentals of how the packaging
> system works, which is not an unreasonable distinction, perhaps. However,
> I don't know that I have a good answer, to this one.
let's see. we get all RC bugs out of the way, and we *keep it that
way*. now we have the opportunity to release a major release at least
once a year, if not twice. simple enough?
> One thing I think can be seen by simple examination is that at least some
> other free software projects do not have this problem (they have their own,
> but that's a separate discussion). FreeBSD, for example, makes regular and
> stable releases. So do some number of other free software projects which
> are just as volunteer-driven as Debian is - so I don't buy "we can't expect
> it of volunteers". If we can't, then we have no business being a volunteer
> project - or we need to change what the project is about.
freebsd can't even do cardbus pcmcia really yet. they have major
problems themselves. but no rc bugs. also, they have less of
a restrictive policy, and a much smaller user-base. they don't have
the image that debian has, and they attract way fewer people per
time-period. read above: keep rc bugs out of the way and release twice
a year. we'll be back in the game (which we never played or left).
> But, whichever way we do it, this is a problem that I consider us obligated
> to resolve, or fail in our upholding of the social contract - because we
> *are* failing our users, today. It might take some time to implement some
> of the changes; we probably won't get it right the first time. Or even the
> second. But I'm willing to fail a few times, in the name of learning how to
> get it to work the right way. How about you?
i am with you. see you on irc tomorrow.
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:"; net@madduck
"nullum magnum ingenium sine mixtura dementiae fuit."
-- seneca
Attachment:
pgppzlcJNKVQa.pgp
Description: PGP signature