On Wed, Aug 20, 2003 at 06:48:51PM +0800, Cameron Patrick wrote: > There were pretty major changes between KDE 3 and KDE 3.1. As a Debian > user, I'd be rather miffed if a new version of KDE came out within a > week of sarge being released ... on the other hand, if sarge is to be > frozen in a couple of months' time, it seems unlikely that KDE 3.2 will > be able to make it in. *grumble* :(
You are, of course, welcome to feel whatever you like. But if you're
particularly interested in running the latest software, you shouldn't
be remotely interested in running Debian stable releases. That's not
what they're there for.
You should expect any software in a Debian stable release to be somewhere
between two months and two years out of date at any given time; with a
bias towards less out of date just after a release, and more out of date
just before a release. As a simple example, if we have releases on the
1st of December each year from now on, sarge's KDE should be between four
and sixteen months old, during sarge's run as stable. By contrast, if we
lived in a magical world where such things were feasible, and delayed
sarge by a week to include KDE 3.2, during sarge's life, KDE would be
between zero and twelve months old. [0]
Now perhaps this really is the difference you're hoping for, but it
sounds to me more like you're a bit disappointed that the version of
KDE in stable will be even a few months out of date, ever. Which is fair
enough: if you're not happy with running a version of KDE that's twelve
months older than the current release, stable's not what you should be
looking at; testing or unstable is.
You should, of course, then be massively disappointed that testing's
version of KDE is some 21-months old. But hey, win some, lose some.
Cheers,
aj
[0] Maths break! The average out-of-dateness over the life of stable in
the two cases is 10 months and 6 months respectively. The difference
is noticable, but not particularly extreme. If you want to make it
look a bit more extreme, you can start counting from major releases
instead of minor releases: that gives you 16 and 6 months averages
instead. For comparison, woody has KDE 2.2.2 which was out at the
end of November, so was eight months out of date when woody released
by that measure; and should we release Dec 1st, will have an average
out of dateness of 16 months counting minor releases, or 19 months
counting major releases.
In general, the average out of dateness is "u + p/2", where u is
how out of date the package is when we release, and p is the period
between releases. u is bounded below by however long it takes us
to become confident with a new release, c, and has an upper limit
of "p_u + c + l_m + l_r", where p_u is the time between upstream
releases, and l_m and l_r are "lag factors" -- l_m is the maximum
amount of time after a package could've been included in Debian (p_u +
c since the last new upstream version), that the maintainer can put
up with user requests and general guilt, before doing an upload,
and l_r is the "release lag" involved in getting the package settled
into testing.
c <= u < p_u + c + l_m + l_r
c + p/2 <= u + p/2 < p_u + c + l_m + l_r + p/2
c + p/2 <= oldness < p_u + c + l_m + l_r + p/2
We probably can't do anything about p_u, and there are definite lower
limits on p -- probably somewhere around six months. In any event, we
have:
general delays:
c -- how long it takes us to be confident a new upstream release
is good, after it's released
p -- release length
variable delays:
p_u -- how often upstream releases
l_m -- how slack the maintainer can be
l_r -- how broken the testing scripts are and/or how broken
the rest of Debian is
Plausible values for KDE core components at the moment are probably
something like:
c = 0.4
p_u = ~10 months for major releases, 2 months for minor releases
l_m = 0
l_r = 10 months
If we released right now, eg, we'd be releasing with the same version
of KDE that's in woody -- that's the impact of the l_r factor. Given
that we've been trying to get KDE into testing for literally twelve
months, it's reasonably safe to say that general breakage in Debian is
the biggest factor in out-of-dateness in stable. We've had numerous
breakages in glibc and other libraries KDE depend on for extended
periods.
Adjusting the release date to be after KDE 3.2's release still needs
to take in these other factors, in particular reducing l_r massively.
It might be possible to do that by saying "everything but KDE has to
be ready for release on 1st December, KDE has to be ready for release
by 31st December", however I'm not willing to make that much of a
special case. Moving the release date in general has problems: any
further into December starts hitting holiday periods, and any further
than December starts losing the benefits of aggressive scheduling.
Stepping back a bit, it's obvious that different packages -- heck,
even different parts of KDE -- will have different values for each
of those variables. Getting them down in general is an interesting
thing to work on. Cutting p is an obvious idea, but the others are
interesting too. c can be reduced by having more upstreams that test
their releases exceedingly well on multiple architectures -- KDE's
a very good example here, the Linux kernel's historically been a
moderately bad example. We can hopefully also improve c by getting
more familiar (and thus confident) with packages before they're
released upsteam -- this is one of the motivations for increased
use of experimental, which will hopefully also allow us to reduce
l_r somewhat.
YMMV.
--
Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``Is this some kind of psych test?
Am I getting paid for this?''
pgpykU2mRK5II.pgp
Description: PGP signature
