Lucas Nussbaum writes (Maintainers, porters, and burden of porting):
However, issues such as miscompilation or broken syscall or libc
semantics are largely undetected. To illustrate this, you can have a
look at #635126 (miscompilation on armel and sparc) and #639658
(forks+threads fun on kFreeBSD, derived from #593139).
To be honest I think it's unreasonable to expect to be able to provide
a full Debian system on an architecture with significant bugs in this
pthreads (much as I personally hate multithreaded code ...).
Our problem is that we have only these three choices:
* Leave affected packages blocked from testing propagation until the
bug is fixed. This is the right answer before the bug has been
properly identified, or if the bug is reasonably tractable and
should simply be fixed (and can thus be expected to be fixed by
anyone who cares in a reasonable timeframe).
* Drop the arch from testing propagation. This is a global change
and will quickly make the architecture a wreck in our archive.
It's a very unpalatable choice and one that obviously porter teams
will strongly resist.
* Change each individual source package affected by a per-arch bug
(perhaps a bug in one of the dependencies) to exclude the affected
architecture. This is a lot of faff and is recording the
information about the bug in the wrong place (and when the bug is
fixed a lot of work needs to be undone). Understandably
maintainers resist that.
* The RMs could manually override testing propagation for certain
bugs. I don't know if this is already done but as a general
solution it obviously doesn't scale - the RMs don't have the time
to research and deal with this kind of thing retail.
Let me make an alternative proposal:
* The root cause bug in the BTS would be given a special tag
(arch-blocker:arch or something). I will call such a bug which
is open and has existed in this state for 30 days a ripe arch
blocker for arch.
Bugs in other affected packages are marked as blocked by the root
cause bug. These bugs, and the arch blocker itself, may be RC, or
not, as appropriate. Let us say ripe arch bug to mean ripe arch
blocker, or bug blocked by a ripe arch blocker.
The effects would be:
1. Any ripe arch bug is ignored for the purposes of testing
propagation.
2. For a package with an RC ripe arch bug for arch:
(i) arch will be ignored for testing propagation
(ii) no builds will be attempted by arch buildds,
automatic tests may be skipped on arch, etc.
The workflow would be as follows:
* If a package has an arch-specific bug, the root cause needs to be
identified, by collaboration between porters and maintainers. This
process should be driven by the maintainer.
* Once the cause has been identified:
- If the root cause is elsewhere, a bug needs to be filed bug
against that other package. If such a bug already exists, the
maintainer of the first package can simply mark their bug as
blocked by the arch blocker. This will allow their package to
migrate unless the arch blocker is new enough.
If no such bug already exists, the maintainer should file a bug
against the appropriate package (toolchain or libc, perhaps),
and immediately tag it as an arch blocker.
- If the root cause is in the package itself, the maintainer or a
porter may tag the bug with arch-blocker:arch. This is
appropriate if the fact that the package isn't portable is a
bug, with which the maintainer wants help from porters, rather
than an inherent property of the package.
If the bug is RC this will effectively allow the maintainer to
drop support for that arch if help is not forthcoming, without
having to modify the source package.
A porter should only remove the arch-blocker tag if the cause
has been clearly identified, and the steps necessary to fix it
are simple and straightforward bugfixes to the package, and
these steps have been set out in the bug report.
* If the cause cannot be determined, whether because sufficient
support from porters isn't available, or for any other reason, the
maintainer should proceed on the assumption that the bug is in
their own package.
The intended result would be that architectures with persistent
problems would become partial. But things wouldn't get worse on those
architectures for packages not affected by persistent arch-specific
bugs.
The approach I describe will hopefully also avoid the necessity for
arguments between maintainers and porters about whose fault a bug is.
When an arch blocker is fixed, all the packages which were affected
are now fully considered for testing propagation. I guess it may be
necessary to force through some transitions which the arch has
missed. I'm not sure how feasible this would be and I would welcome
comments from RMs.
Ian.
