Steven Chamberlain writes ("Re: Making Debian ports less burdensome"):
> I think the testing autoremoval thing started out the same way, it
> merely reported long-standing RC bugs, but removal was manual in the
> beginning.
>
> Okay, perhaps I should start working on:
>
> * A report of out-of-date packages in sid, for each arch; ideally
> try to correlate those with FTBFS bugs, and highlight where there
> isn't one already filed. If it could generate a template bug report
> ready to send (with appropriate usertags or X-Debbugs-Cc: headers),
> that would be even better.
>
> * A report of FTBFS bugs that have not had activity in some time.
> (Perhaps filter out FTBFS that affect many arches like amd64/i386).
>
> Where a bug has a patch that just hasn't been applied by the maintainer,
> a porter NMU might be justified. It would be nice to have a list of
> those to show to a DD who may be able to help.
>
> If the bug has no patch, maybe it could produce an ftpmaster RM bug
> template ready for someone to send; showing the reverse-depends too.
Sorry to be discouraging, but I don't think this is the right
approach.
Of course there are tradeoffs between the costs of this kind of bug to
less-popular architectures, or to less-popular packages, but I don't
think this is the right way to make that tradeoff.
If an individual package that someone cares about wants to drop an
arch for a difficult-to-fix bug, then that's one thing. I definitely
don't want to see us routinely dropping packages from an arch, without
anyone having taken a decision about whether this is the right thing
to do.
Toolchain problems with sufficintly wide impact ought to be dealt with
by deprecating architectures, not by dropping packages piecemeal.
Conversely most portability bugs are pretty easy to fix if you have a
repro.
Thanks,
Ian.
