Hi.
Packages are auto-removed from testing when they are RC-buggy.
Could we do something similar in unstable, for Debian's ports?
A FTBFS on any *one* release arch, delays testing migration on all
arches. It makes the package RC-buggy, which could trigger its
autoremoval from testing if not handled. Before release, the
out-of-date package must either be fixed, or ftpmaster requested to
remove it on the release arches where it FTBFS.
There are some things I think we should do routinely, and I suggest we
start to automate:
* FTBFS bugs should be filed. Perhaps not immediately, but when a
particular port is starting to delay testing migration. Porters
need to actually be copied on these bugs, either to a mailing list
and/or usertagged would be nice; since a lot of the time the
porters simply don't get any notification.
* If left unfixed, the bugs should trigger an auto-removal from
unstable so that the package can migrate on the other arches. It
also means the FTBFS bugs can be downgraded to non-RC, and helps
packages to get back into a releaseable state. And it cleans up
the archive, allowing old source packages to go away after
transitions complete.
* Some packages are too essential to autoremove. The testing
autoremoval script has some list of those and we'd like to define
something similar for each port. Then, the bulk of porting efforts
can be concentrated here, where it matters most. RC bugs in these
packages might be reasonable justification for a port not being part
of the official release.
Hopefully we'd see ports with the 'core' packages in good shape, and
therefore being releaseable. Even if some of them are very lightweight,
not having all the desktop environments, tasks, or OpenJDK for example.
Having a stable set of build-essential packages is important for ports
to get DSA-administered buildds, for developers to be able to run it,
and for the port to progress further.
Regards,
--
Steven Chamberlain
steven@pyro.eu.org
Attachment:
signature.asc
Description: Digital signature