Re: Re-evaluating architecture inclusion in unstable/experimental
On 9/29/18 8:48 AM, Ben Hutchings wrote:
> On Fri, 2018-09-28 at 14:16 +0200, John Paul Adrian Glaubitz wrote:
> [...]
>> Furthermore, several of the ports are in very healthy condition and
>> even surpass some release architectures. The powerpc and ppc64 ports,
>> for example, build more packages than any of the mips* ports.
>
> I would be very happy to never have to wait for MIPS builds again.
I don't have a problem with waiting for slow machines. I just think this
shows that the decisions what becomes a release architecture and what
doesn't isn't purely meritocratic.
>> As for the kernel maintenance, except for Alpha, all the ports have
>> at least one kernel maintainer:
>>
>> * hppa: actively maintained by two people who also maintain the toolchain
>
> But the hardware is EOL since 2008.
Well, the hardware is usually build like tanks and if people keep using
it and others keep maintaining it, why throw something out when it's
still working?
SAP is still maintaining and supporting JDK on PA-RISC and IA64
for paying customers, FWIW.
>> * ia64: maintained by one paid developer at Intel
>
> To the extent of 2 whole commits this year! I'm pretty sure this is
> not actually his job any more.
Jason Duerstock talked to him and he said, he's still doing this as
a job at Intel because basically no one told him to stop doing it.
>> * m68k: maintained by multiple independent kernel maintainers, at least
>> five people involved upstream; port is also getting new drivers
>
> But the available hardware is either too slow to be useful, or only
> available through crowdfunding (maybe, eventually).
Yes, this is being worked on. There are FPGA-based implementations which
allow to boost Amiga and Atari hardware to considerably higher speeds. It's
not done on a large commercial scale, so things take longer to develop.
But people are working on it and bugs get fixed, code maintained and
drivers added.
>> * powerpc/ppc64: maintained mostly by IBM people
>
> IBM looks after 64-bit configurations, so ppc64 is covered but not
> powerpc.
Well, I have had people from IBM fix 32-bit PowerPC code. There is naturally
more involvement behind the 64-bit stuff because that's where the commercial
interests are.
>> * sh4: maintained by two kernel maintainers
>
> That may be, but the Debian port isn't stable enough to *build* a
> kernel: https://buildd.debian.org/status/logs.php?pkg=linux&arch=sh4
That's a compiler bug, I know.
>> * sparc64: used to be maintained by a team at Oracle but Oracle recently
>> changed their mind about Linux on SPARC; now it's back to
>> David Miller and some additional volunteers
>
> Oracle laid off their SPARC team. Fujitsu has another SPARC processor
> in development, but only for supercomputers (and they seem to be
> switching to Aarch64 later). So we can expect this architecture to
> slowly fade away now.
What Oracle is really doing and planning isn't really clear. I have talked
to multiple people at Oracle directly and the consensus is that there isn't
a consensus what is going to happen next.
But again, this just supports my point that the decisions which ports
become release architectures is mostly driven by commercial interests
and not whether there are users in the community. Or is there actually
a large community of POWER8 and z-Series Debian users?
>> * x32: maintained by the people who maintain the x86 port of the kernel
>
> H. Peter Anvin did the original port in 2012, but so far as I can see
> none of the x86 maintainers have done any development on it since then.
> And yes, development work has been needed:
>
> - x32 has 64-bit time_t and that never worked quite right. This may
> have finally been fixed this year by Arnd Bergmann's work, but I'm
> not sure.
> - syscall restart was broken until 2015 when someone actually tested
> it.
> - There have been several regressions specific to x32, some of which
> stuck around for a year or so before someone and fixed them.
>
> [...]
>
> So, by all means have fun working on these ports, but aside from ppc64
> I don't see any prospect of them meeting release qualifications.
I think the problem that I have is that the release qualifications are
not practical in the sense that they don't necessarily meet our users
expectations. As I said, I think a tier-based system would be more
practical as it would allow ports to be degraded more gracefully instead
of just kicking them out like it was done with 32-Bit PowerPC.
I don't have a proper concept yet, but I think the OBS approach is more
versatile, for example.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Reply to: