Re: Maintainers, porters, and burden of porting

[Lucas Nussbaum <lucas@lucas-nussbaum.net>]

On 30/08/11 at 10:34 +0100, Lars Wirzenius wrote:
> But both are wrong, too: it's always the job of both. It's not supposed
> to be a struggle between maintainers and porters, but everyone in
> Debian against bugs and shortcomings of our system.

Sure. But what happens when bugs and shortcomings are too hard to solve?

For packages, we have several mechanisms to deal with packages that are
not of releasable quality. We can remove them from testing, put them only
in experimental, etc. Those mechanisms are very flexible, and allow for
temporary decisions.

Regarding architectures, we made releases with a semi-official status on
two occasions at least (etch-m68k and kfreebsd in squeeze). Maybe we
should officialize the fact that when we make stable releases, we have
two sets of architectures:
- the ones that are fully supported
- the ones that are too experimental to be fully supported
Being in the second set would be fine, and would not be a step towards
being thrown out of Debian. Maintainers should still help porters get
their packages ported, etc. But it would allow to relieve some of the
pressure regarding testing migrations, for example. And it would be easy
to move architectures from one set to another between releases, or even
imagine that all architectures start each release cycle in the second
set, and need to show that they can be promoted to the first set.

And if we generalize this, it means that debian-ports.org could actually
be part of Debian, because most of the architectures there could clearly
be in the 'too experimental to be fully supported' set.

I've always wondered what was the point of having some architectures
part of stable releases as official architectures. Sure, they are very
useful as experimental architectures, and very fun to work on, but it's
unlikely that people will use them on production machines because the
hardware is too old & slow, or some key piece of software is too
unstable.

Lucas