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

Re: Q for all candidates: (Old) Architecture Support

On Wed, Mar 17, 2010 at 03:49:16PM +0200, Yavor Doganov wrote:
> 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.

I agree on the stance that it's essentially dead now, yeah. The latter
part is not precisely true. If someone were to fix the technical issues
with the port that exist today--which would qualify as a
'miracle'--there's a fairly good chance that the port might be
resurrected; the m68k porters were always rather enthousiastic about
their port.

[...list of problematic architectures snipped...]
> 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...

Agreed on those points.

> 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 agree.

>     (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?

When package maintainers are informed of architecture-specific bugs in
their package, they should listen to porters, and actively work on the
bug, rather than expect that a porter will fix it (which happens rather
often for architectures that are in a problematic state, because "it's
not a release architecture anyway", thereby only enlarging that
architecture's problems). Porters can't fix every architecture-specific
bug; and reading unfamiliar code to hunt down why a bug fails on one
particular architecture isn't always the easiest thing to do.

Of course porters are available to help, since they're supposed to know
the architecture, but that's a different matter.

> Do you think it is "goodness" or you're in the "good riddance" camp?

I'm clearly in the former camp.

> Extra question to Wouter as a (former?) porter and buildd admin

I'm still a porter; while the m68k port is mostly dead, there are still
buildd hosts running that occasionally manage to successfully build
something; and that is still uploaded. But these are far and few

Also, I am an admin for one powerpc host.

> (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.)

Not entirely.

There were people who contributed to the upstream kernel, yes. There
were no people active in the Debian m68k port on the toolchain.

That was one of the reasons of our decline; we had no in-house knowledge
to fix our toolchain, and had to rely on outside contributors. I did
manage to hunt down a few problems by myself, but it wasn't enough to
turn the tide.

>   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; [*])?

Because we have no usable and modern toolchain ATM. If that were ever
fixed, we could probably get in again at some point.

The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.

Attachment: signature.asc
Description: Digital signature

Reply to: