Q for all candidates: (Old) Architecture Support

[Yavor Doganov <yavor@gnu.org>]

Debian has been known through the years for its excellent support for
many architectures.  In theory, a released arch should be as stable as
the common/popular archs.  (In practice, it is/was pretty close, which
is good enough.) 

This asset is not something to be proud of because of shallow
marketing reasons -- it benefits the whole Free World as many bugs are
uncovered, reported, and fixed, quite often by Debian people.  It
would not be incorrect to say that, having in mind how many packages
are available in the archive, and the GNU/Hurd + GNU/kFreeBSD ports,
Debian is the most comprehensive testground of the GNU system.

There is a disturbing and unpleasant tendency (which
probably has its roots in the Dark Times, i.e. the Vancouver Proposal)
to drop support for some problematic archs as years go by.  That's
entirely understandable, but:

- m68k was the first "kicked out" arch.  AFAICT, it is essentially
  dead now and not even a miracle can save it.
- alpha will not be released with squeeze; I dare to speculate that it
  will be in the position of m68k within a release or two.
- Debian is the last GNU distro with a sparc port (Gentoo has sparc
  too, but it's actually sparc64); squeeze+1 will probably drop sparc.
  (Again speculation/clairvoyance: sparc will follow m68k's footsteps
  pretty soon too, especially having in mind that there's no or little
  upstream support.)
- hppa was (and always is, it seems) at great risk, although thanks to
  the Herculean efforts of the porters it is in a good shape (as far
  as I can judge) now.
- mips/mipsel are probably the most hated archs by DDs in the past few
  months :-), and there's no ironclad way to secure their future too.

So, having in mind the obvious conclusions a sensible person could do,
namely

* Support for old (and not only old) architectures cannot be infinite;
  and there's a line to draw somewhere when it comes to a release.
* There should be an entitiy within the project to decide which arch
  gets released and which not, which one is blocking the whole release
  process and ought to be ignored for testing propagation, etc.
  Naturally, such entity is the Release Team, and their criteria don't
  seem bad.
* There's not much a DPL could do except some publicity and
  RFH-oriented efforts which are known not to work well...

the apparent solution to the problem is:

    Porters are an extremely valuable resource, and the survival of an
    architecture in the distribution is impossible without skilled
    people who can fix the hardest problems, assist upstream
    (especially toolchain packages) and Debian maintainers in fixing
    the issues that prevent a specific arch to meet the release
    criteria.
    Therefore, it is essential to preserve, and even grow, such
    resources by doing all possible to attract people with sufficient
    knowledge and also pass that knowledge through.

    (I hope that most of you remember how much insightful Thiemo's
    analysis about mipsen problems were.)


If you managed to keep up reading until this point, my question to the
candidates is:

What do you think the project should do (with or without or regardless
of your help as potential DPL) to preserve this goodness (maximum
supported architectures) for as long as possible?  Do you think it is
"goodness" or you're in the "good riddance" camp?


Extra question to Wouter as a (former?) porter and buildd admin (feel
free not to reply at all; and for other candidates -- feel free to
reply if you want to):

  IMVHO the m68k team was one of the most energetic, enthusiastic and
  tireless porter teams.  It included many knowledgable people who
  contributed upstream as well (Linux, GCC, glibc, binutils, etc.)
  The release team made it clear that m68k can return as a release
  arch at any time, so the kick-out for Etch was (supposed to be)
  temporary.  Why do you think the m68k port is not doing very well
  (to put it mildly; [*])?


[*] It's like the old joke when a person sends a supposed-to-be
    "delicate" telegram to a relative: "John not feeling well.
    Funeral tomorrow noon."