Re: Debian development and release: always releasable (essay)
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
Reply to: