On Tue, 08 May 2001, Herbert Xu wrote: > Henrique de Moraes Holschuh <hmh@debian.org> wrote: > > Most of us don't bother too much with testing, unless we're trying to get > > something into testing for one particular reason or another (such as, the > > package in testing is too damn buggy, or has a security hole). > > FWIW, I do all my development under testing. I virtually ignore unstable > unless I need a specific package from it. AFAIK, I cannot do that. If I build against testing, I help the breakage by adding yet another package that depends on the outdated libraries that are in testing, therefore helping those libraries to be held instead of upgraded. It's a positive feedback loop. Unless I misunderstand testing, obviously, and such loop does not exist. That's why I don't bother with testing, unless I'm dealing with a urgency high or critical upload; In that case I'll happily request the version of the package in testing to be *removed*. If it happens to be very important package (none of mine are, AFAIK), I'll compile it in a testing chroot, upload it with urgency high or critical, and downgrade all RC bugs. As soon as it gets moved into testing, I'd upload a urgency critical package built in a proper sid chroot, and restore the bugs to their proper severity. Xu, I don't claim to understand your packages better than you. I have no idea where on the dependency chain they are; maybe they don't affect other packages in testing at all. But that's not the case for my packages. Maybe I misunderstand the testing mechanics, and libs will be always upgraded when their dependencies allow it, thus flushing a lot of packages from testing. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Attachment:
pgpw_DPcWcf0z.pgp
Description: PGP signature