On Thu, May 09, 2013 at 08:49:51PM +0100, Lars Wirzenius wrote: > * Remove RC buggy packages sooner rather than later. An RC buggy > package should be removed at soon as possible: when the bug > is identified, allow a bit of time for the bug to be verified > (was it actually an RC bug?), but after that, remove the package > from testing, preferably automatically. If the package has > reverse dependencies, remove those as well. This keeps testing > releasable. The removed package can and will re-enter testing once > it gets fixed.
The value of package removal, is to clarify that the release will not wait for this package. I fear that having a flaky testing distribution with packages frequently removed and added again would cause problems on its own merits. On the other hand maybe removal is not the thing we are aiming for? I am aware of at least one case where a removal notice (the actual removal never happened) caused a third party to fix a package, because maintaining it himself would have been more work. Maybe making those removal notices more visible would help getting further people involved? What about feeding removal notices to planet.d.o? And yeah, more of them should help as well. To that end improving the rc-alert output (and making this utility more visible to end users) could improve the situation as well. > To reduce the sting of optional packages missing the release, we > should consider whether we're willing to introduce new packages > in stable point releases. Obviously, only packages that have > no new dependencies could be introduced that way, so things that > require newer versions of the packages already in stable would not > be eligible. But it means that if a package was in the previous > stable but missed the current stable due to unresolved issues at > the time of the releease, we could still get it back in and it > wouldn't have to wait another year or two. This idea has a negative side effect. If my pet package is missing from a stable release I am probably tempted to wait with upgrading, because there is a chance for it to be reintroduced. This even applies if the package does not end up being added due to the scarce availability of time machines. The current policy of not extending a stable release actually provides a benefit: clarity. Helmut -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130511055427.ga19...@alf.mars