Re: problems with the concept of unstable -> testing
Russell Coker schrieb:
[...]
> While changes to the processes for uploading new packages are probably not
> desirable when a freeze is starting, it seems that Lenny might be delayed for
> a while. So if the GR on the Lenny release ends up actually changing
> anything then I suggest that we make some changes to prevent stalling all
> development.
I support that request. Not only is unstable quite outdated already
(bleeding edge?) it also becomes more and more a problem since the
kernel and Xorg aren't updated anymore in unstable. That means that
newer hardware (especially Laptops) don't fully work anymore (WLAN,
Graphic, Sound).
Since we're making it very hard for our users to get their new hardware
working seamlessly, unstable becomes more and more unattractive compared
to other distributions.
Some suggest to cherry pick packages from experimental, but first some
packages like the kernel aren't even available there and second, since
experimental is not part of the unstable > testing > stable flow, it has
the aura of sandbox/playground/if-your-box-breaks-its-your-own-fault.
And officially we don't even recommend using unstable, aren't we? So for
me that argument is invalid.
What I'd like to see is a solution where unstable is *never* frozen,
maybe by replacing the current frozen unstable with something temporary
and putting it between unstable and testing, where all the fixes go
while all the new stuff can still go into unstable but cannot enter the
next step while we're in the freeze:
Normal:
experimental || unstable > testing > stable
Freeze:
experimental || unstable || $something frozen > testing > stable
Basicly we already have this with:
experimental || unstable > testing > stable
but that's an abuse of experimental (as a substitute for unstable), not
everyone uses it to upload new packages and it still has the
I'll-break-you-box-aura.
Cheers,
Bastian
--
Bastian Venthur http://venthur.de
Debian Developer venthur at debian org
Reply to: