On Tue, Mar 22, 2005 at 10:55:05AM +0100, Erik Schanze wrote: > Joerg Friedrich <Joerg.Dieter.Friedrich@uni-konstanz.de>: > > reading larger parts of the recent threads triggered by the > > 'Vancouver proposal' brought me to write this mail. > > > > Over the last two years testing became more and more a second > > (almost) stable distribution instead of being a preparation area for the > > next release. Now there is even security support it is not a officially > > supported release. > > > > Nevertheless I believe that testing is a good idea. But it suffers from > > some problems. > > 1. The number of packages > > Debian never stopped growing, and there are packages which are > > unmaintained but they are still in the archive. > > Hey, if noone is willing to maintain a package, wait a grace period > > (30 days) and remove it from unstable and testing. If somone needs > > it, he could step forward and maintain it. This doesn't seem like a very good heuristic to me, and it's not something that's currently a major source of work for the release team. Currently, packages in testing are candidates for removal if they've had release-critical bugs open for more than a week; it doesn't matter if they're orphaned or not. Likewise, if a package *doesn't* have release-critical bugs, it doesn't matter if it's orphaned or not: being orphaned for a month just isn't a good indicator of the utility, or the quality, of the package. Auto-removal of orphaned packages from unstable is also bad if it's an orphaned library that's still needed (which happens often enough). > If RC-bugs remain unfixed for a period, I agree with removing, but this is > common practice, I think. Perhaps somethimes too slow. ;-) Hmm, 7 days is too slow? > Perhaps wnpp websites could be improved to show a ranking list of packages > which will be removed soon and why. A Section "Removal Candidates" in DWN > could be also helpful. The thought is to use the new debian-testing-changes mailing list to notify when (and why) packages have been removed from testing. Currently, we don't have any automatic way to notify maintainers of a package's removal from testing, which is bad. I don't think DWN is a good choice here, though; weekly reports won't be a very good starting point for people interested in working on the packages. > > 2. Unstable to testing migration is one way > > Packages migrate to testing automaticly, but removal requires manual > > action. > > I noticed that some developers work hard to get a package or a > > specific version into testing, but if a new (rc) bug occurs after the > > migration, nothing happens. > > At least optional and extra packages should be removed automaticly if > > a new rc bug emerges. > > E.g. if noone claims to fix the bug, an extra package should be > > removed from testing after one, an optional after two weeks. And also > > all packages which depend on the buggy one. Again, I don't think there are any grounds for automating this. RC-buggy packages that are clearly expendable do get removed from testing quite quickly. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature