Debian doesn't have to be slower than time.
Every time folks complain about Debian taking forever between releases, and
how each one is taking longer than the one before (I've seen estimates of
3 years for Woody+1, at the current rate of expansion...), the developer
community gets frustrated that they have no way to fix it, and take the
brunt of the complaints.
But what can be done about it?
Having *done* release management on commercial projects where a failure to
keep a reasonable timeline (for whatever your business model deemed to be
reasonable) meant your company failed... I see the following problems with
the release process, and offer some possible solutions. Please note: I'm
not just dumping a Policy bug because it seemed more useful to float it and
get commentary first. There may well come one out of all this, depending on
what gets said.
So, without further ado:
* Why does Debian take so long to release?
* Why does it *matter* that Debian takes so long to release?
* How do we avoid putting out buggy releases, while going faster?
* How do we avoid running out of toy names?
* How do we know when we've done a major-version release?
* Why should we bother with any of this?
In order:
* 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.
* Why does it *matter* that Debian takes so long to release?
Perhaps it doesn't. It depends on what your goals for Debian are. 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.
The single most common reason I have heard from experienced Linux users -
not new folks just off of Windows, but years-experienced Sysadmins who know
the power of centralized configuration, prompt security updates, and having
bug-purged software - is that these things cannot come at the current price
of Debian's stable release being vastly out of date.
* 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.
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.
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.
* How do we avoid running out of toy names?
Make Pixar do a new movie with more characters.
* 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.
* Why should we bother with any of this?
Because both our common sense, and our Social Contract, make it clear that
the current situation is untenable.
Now.... for some free-form rambling that has most of my suggestions for
actual fixes, and why they address the problems.
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.
But I don't think that's necessary. I think we can fix it by changing how
we do things. We need to stop driving releases with goals that are often
large, ill-defined, prone to creep, and in some cases (crypto-in-main),
completely outside our control. Instead, if we want releases which keep up
with a moving time flow... we need to base them on time. A release every 3
months. Or 6. Or 12. Hell, 24. Find a number that balances our ability to
make necessary changes against the need to remain reasonably current with
the software we package - and then *stick with that number*.
Problems happen. Failures happen. That's life. FreeBSD's release schedule
sometimes slips by a week or two - even a month, once, I've been told. But
that was considered a *failure*, a problem. Not "oh, we'll just push the
rest of the schedule out by 2 weeks". If we define our releases such that
we can never fail at them, then we will never fail - but there will come
a time when we never succeed, either, because the target is moving faster
than we are.
A timed release schedule does, of course, raise questions of what should
be done within that time - and what *can* be done, in that time. This is
the point where I would say we must apply the same feedback process that
is used in (successful) commercial release management - ask the customer
what features they want, what their priorities are for those. Then you set
those in order, from most important to least - and use your development
process to estimate how long each will take. If your first task (hell, if
*any* task) takes longer than a release cycle, it's too big. Way too big.
Break it down, re-order the list, and start over. Once you know how much
you can get done before the next release, you set *those* as your goal for
it, *within* the constraints of your time - and get to work on them.
If all goes well, you're done with them, have them tested, and ready to go
in time for the next release. You release, you talk to your customers (or
in our case, users) again - and start over. Lather, rinse, repeat.
If things break, or there are problems... perhaps the release gets delayed
by a week while the crack team of bug-smashers goes over the two RC bugs
that are left. There are only two because we all write good software and
use things like regression testing to make sure it works, of course, right?
So most of these are problems with architectures we don't have access to,
and we turn to our fellow developers who specialize in those, and ask for
their advice on how to solve it. The bugs get fixed, the release goes out a
week late, we say "Sorry, folks. We'll try to do better next time." And we
go back and do it all again.
I will note, for the record - Debian *does* make release every few months,
today. It isn't terribly consistant, but it happens frequently enough to
keep a few things up to date. We call them "point releases" - and if they
covered most software, rather than just security updates and things that
the author considers so crucial that they're willing to hammer their way
through the red tape to get it added, they'd be somewhat more useful than
just adding the security area to the APT sources list. Don't get me wrong
on this one - I think they're a great thing. I just want *everything* to
be following their example. Hell, maybe that's how we avoid running out of
toy names... major releases are package software/system upgrades, minor are
things like "base changes to perl6" or "libc6.1 upgrade" - and the point
releases are just software updates.
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?
--
***************************************************************************
Joel Baker System Administrator - lightbearer.com
lucifer@lightbearer.com http://users.lightbearer.com/lucifer/
Reply to: