Universe QA for Hardy

[Emmet Hikory]

On 11/1/07, Michael Bienia <michael at vorlon.ping.de> wrote:
> On 2007-10-31 12:37:28 +0900, Emmet Hikory wrote:
> > Hardy should have no Not Built from Source, Failed To Build From
> > Source, or Outdated packages:
>
> What should happen to packages which still depend on packages in the NBS
> list? See e.g. sear now (stuck in 6 lib package transitions) and IIRC
> FTBFS with the new packages (needs porting to the new API).

    For gutsy, several of us worked to port all the packages to the
new APIs.  I suggest the same for Hardy, only more so.  Starting this
before DIF is not entirely useful unless we know there won't be
updates, but initial work is welcome (on the other hand, we
transitioned flac 3 times for gutsy, and I wouldn't want to see that
again).

> What should happen with packages which FTBFS and where no fix is
> available currently?

    Someone should write a fix.  For each programming language in
which we have packages, we can likely find at least one programmer,
and most FTBFS issues are relatively simple architecture-specific
issues, API changes (where the library authors often provide a
migration guide), or changes in the build tools, which tend to be well
documented.

> AFAIK it's not possible to remove the binaries only, so the whole
> package must be removed from the archive.

    If it warrants removal, yes.  I don't imagine we'll need many
removals for FTBFS if we're attentive.

> - Does it matter if the package FTBFS on all architectures or only on
>   some?

    It definitely matters for all supported architecures.  Ports are a
little more flexible, although it would be nice if the ports also
didn't show these issues.

> - When should the package be removed? And what about reverse (build-)
>   dependencies?

    I'd like to restrict package removals to things clearly not
useful, rather than NBS/FTBFS/outdated.  I firmly believe we have the
skills to fix all of these, as long as we have the tools to track
them.

> - Is it allowed to enter again when a fix is available? When is the
>   deadline?
>
> We should ask the archive admins about their opinion on this point as
> it's them who need to source-NEW and bin-NEW the packages again.

    With the restricted removals I envision, I don't imagine anything
removed should re-enter.  As a result, I don't imagine much impact on
archive-admin workload.

> > If requesting the
> > removal of a package, please consider:
> >
> > 1)  Removal of the package should not break any other packages
> > 2)  There should be a replacement that provides the functionality
> > 3)  There should be a transition plan for users
> >
> >     In some cases this means the upload of dummy packages to point to
> > the replacements.  In some cases this means adjustment of dependencies
> > / recommendations / suggestions to indicate the correct package.  In
> > some cases, no action is required.
>
> Add 2): What about software which is dead upstream and the package got
> removed from Debian? Should we keep that package? What if no replacement
> is available?

    I'd suggest it depends on why it was removed from Debian.  If it
was just RoM, and someone thinks it really should have been orphaned
instead, I can imagine keeping it.  In most cases, I think removed
from Debian likely means should be removed from Ubuntu.  Dead upstream
is different: if the package is still useful, and still maintained
(either in Debian or in Ubuntu) I don't see any value in removing it.
As cruft develops, this argument becomes weaker, and after a while
there should either be an alternate solution, an upstream fork, or the
package should be dropped.

> Does the requirement for a replacement also applies to library packages?

    Yes, and even more so.  Libraries have clients, and the client
packages need to work.  I'd really like to stop maintaining libjsw,
but I don't want to remove Search & Rescue.  Maybe I'll get around to
porting Search & Rescue to the new joystick interface, or maybe
someone else will.  On the other hand, I don't feel we have a
responsibility to support APIs not required by software in our
archive: users with locally compiled or third-party software should be
reviewing the release notes and planning appropriate adjustments as
part of their internal upgrade plans.

> Add 3): Should a transition plan for already removed packages (like
> apache1 or php4) be added?

    Loosely, yes.  For any package in Gutsy or Dapper for which there
is a sane replacement in Hardy, we should make best efforts to ensure
that an upgraded system continues to work.  While we can't support a
user's local PHP4 code, we can make sure that an upgraded system has a
working apache2/php5 installation when the upgrade is complete, so
that the client can deploy their locally modified php5 code, and
everything just works.

> How automatic should the transition be? What if no automatic transition
> exists?

    I think the goals should be 1) minimum pain, and 2) minimum number
of binary packages not distributed by the archives left on the system.
 Sometimes this means providing empty transition packages.  Sometimes
there is no good solution.  Where we can't do anything, we should at
least have investigated, and draft good release notes.  Ideally, users
without custom installed software should be able to continually
upgrade LTS to LTS or release to release and never end up with
anything in "obsolete or local".  I'm not certain reaching this state
is possible, but it remains ideal.

-- 
Emmet HIKORY