Re: Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
-----BEGIN PGP SIGNED MESSAGE-----
On 2008-06-03 19:59, Pierre Habouzit wrote:
> On Tue, Jun 03, 2008 at 04:18:46PM +0000, Joey Hess wrote:
>> Pierre Habouzit wrote:
>>> No it's not. The principal goal of testing is to evaluate what would
>>> be our next stable if we tried to release *RIGHT NOW*. Packages with RC
>>> bugs cannot be part of a release, so must be kept out. *I* don't really
>>> care about testing being fully usable all the time, I care about it
>>> being a good representation of what could be released. Testing was meant
>>> as a release management tool, not really as a usable distribution.
As I've understood it so far, testing is for 'people trying to help the
developers by testing the software prior to release'. If too much of
testing becomes _either_ unusable _or_ unavailable, it won't be possible
to use it for testing and evaluation.
>> If testing is not intended to be a usable distribution, then the d-i
>> team should stop trying to make releases using it. d-i needs a usable
>> distribution to install, or we don't get any, well, testing.
>> This will, as you perhaps know, require 2 to 6 months of development
>> work after testing *does* become a usable distribution (ie, post-freeze)
>> before a d-i can be released for it.
> It depends of your definition of usable. I don't think it's usable on
> a daily basis because:
I use testing on a daily basis and it has been usable for me. I rely on
it for my work, and in the past this has not been a bad decision.
I at times prefer testing for the following reasons:
- - new laptops (the ones I tried) have or had bad hardware support
(especially back on woody!). (That might improve after etch-and-a-half)
- - At that time I didn't know how to compile a kernel and did not know
about backports etc. I was new to linux.
- - RC bugs won't get fixed in stable (at least some won't) . By
definition, there are 0 RC bugs when stable becomes stable, but all the
ones that are found later, usually are just 'ignored' up to the next
stable release. (At least that is my experience). This has actually been
the other compelling reason for me to switch to testing.
- - It happens that newer versions of critical software are just so much
better that it warrants an upgrade of the system (YMMV) .
> * it doesn't get a lot of security updates (those must migrate first,
> and it's not often possible, though testing-security partly
> addresses that, I don't know how well it's up2date) ;
> * on a regular basis some packages are broken because it depends on an
> RC to be fixed and to migrate (variant of the previous one for RC
> bugs) ;
In my experience, testing used to be not much more broken than stable
. I really hope that that won't change. If something is broken in
testing, it has the advantage that chances are higher that it will be
fixed soon (RC or non-RC) -- as opposed to stable.
> * on a regular basis some packages are removed and must migrate again,
> and that's good because it's better not to have a package than a
> completely broken one. Brokeness is unstable.
I agree with this. I hope that packages are removed, if they are
*completely* broken. It might be a difficult decision at times, but *I*
definitely prefer to keep a package in testing, as long as it is usable
for some/most (desktop) users.
Finally, why don't I just sid? Because I enjoy the silence, when finally
my laptop migrates to stable and the frequency of upgrades goes down by
orders of magnitude.... 8-)
.... and then my laptop breaks and I have to buy a new one :-(
(I'm not a programmer, I am just doing scientific work with a computer.)
Just my humble opinion.
Cheers, and many thanks for keeping testing in such a good shape!!!
 I might be biased at this, since I rely mostly on scientific
software and things like latex or gnuplot, that are inherently more
mature than things like multimedia, compiz etc.
 From http://bugs.debian.org/release-critical/ it would appear that
testing has less RC bugs as stable.
 backports.org is not always as good as testing, especially if we are
talking about a bunch of packages or if the ones that are important to
you are missing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
-----END PGP SIGNATURE-----