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

Re: Maintainers, porters, and burden of porting [and 1 more messages]

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

    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

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.


Reply to: