[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Making Debian ports less burdensome


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.

Steven Chamberlain

Attachment: signature.asc
Description: Digital signature

Reply to: