Re: Maintainers, porters, and burden of porting

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

On 31/08/11 at 11:40 +0200, Andreas Barth wrote:
> * Lucas Nussbaum (lucas@lucas-nussbaum.net) [110831 07:34]:
> > 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.
> 
> This doesn't work. If the architecture isn't considered anymore for
> testing migration, we'll soon end up in a state where packages are too
> broken (just consider library transitions where a random package gets
> build delayed). However, good news is that we are currently improving
> our testing migration scripts to allow some overlap during library
> transitions on all arches in most parts of the release cycle.

First, if we are not supporting stable releases on a given arch, it also
means that we don't need to release with exactly the same versions as on
the other architectures. I think that it's what we did for etch-m68k.

I understand that it's a lot of work to re-add architectures to testing
transitions, but then, on the other hand, you get the benefit that
transitions no longer get blocked by this architecture during the rest
of the release cycle.

> > 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.
> 
> You mean like arm tablets, mipsel laptops, kbsd routers?

Are there known, hard-to-solve problems with the kernel, libc,
toolchain, etc. on armel and mipsel? If there aren't, and the buildd
admins+porters think that it's useful to have them as officially
supported architectures, then it's fine to keep them that way, of
course.

Lucas