Re: Re-evaluating architecture inclusion in unstable/experimental
I just saw this mail this morning by accident while browsing the
archives, I am not subscribed to debian-devel.
> The ftpmaster team would like to clarify which Debian ports should
and/or would like to continue to be part of Debian unstable and
I'm not sure what context you are referring to? Are you talking
about architectures that are present in the main archive or do
you also include Debian Ports which has its own FTP server and
buildds maintained outside DSA?
> As outlined on the Debian Archive Criteria page, the key points to
consider are whether the architecture has been part of a stable release,
whether it is *likely* to be part of a stable release, as well as
whether it currently has a sensible number of active maintainers.
All ports in Debian Ports have at least one maintainer otherwise
it wouldn't be possible to keep the pace with unstable.
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.
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
* ia64: maintained by one paid developer at Intel
* m68k: maintained by multiple independent kernel maintainers, at least
five people involved upstream; port is also getting new drivers
* powerpc/ppc64: maintained mostly by IBM people
* sh4: maintained by two kernel maintainers
* 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
* x32: maintained by the people who maintain the x86 port of the kernel
> Whilst you may be happy to continue the work of maintaining the port
regardless, don't forget that excess or otherwise unnecessary
architectures involve a shared maintenance burden as well as incurring
non-trivial requirements on mirror/Debian resources.
Debian Ports has its own mirrors. Besides, I think one of the main selling
points of Debian is its portability. If we take away this feature, we become
If the maintenance burden is too high, it might be an idea to switch to
a more flexible and powerful infrastructure like SUSE's OBS which makes
handling of new ports much easier. It's very easy to set up your own OBS,
so people within SUSE do that to maintain their own ports, for example.
> The statistics and graphs available on the debian-ports page may
provide some objective statistics or reflection on the actual
suitability of your architecture's continued inclusion.
Jepp. And as you can see, several ports that are thought to be dead long
time ago are healthier than some of the official Debian release architectures
simply because there are huge communities behind it.
The m68k port has a very strong and enthusiastic community which is why
the port has already survived multiple other architectures in the kernel
like TileGX and similar. There are people building new m68k hardware, writing
new drivers and there is even an ongoing effort to create an m68k backend
for LLVM so that we can eventually even start building Rust packages (I
have already added partial target support for m68k in a local Rust branch).
So, it's not always a purely technical decision whether a port remains
a release architecture. It's also often highly political and somehow
also influenced by commercial entities. Although I think Debian, being
a community distribution, should be more oriented towards its community and
not towards commercial interests.
> So, in the first instance, would you like to continue being part of
All Debian Ports architectures  should remain part of unstable and
experimental and are very actively maintained by the Debian Ports team.
You can find us in #debian-ports on OFTC.
FWIW, we have our own instance of the transition tracker:
>  https://buildd.debian.org/stats/graph-ports-big.png
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - email@example.com
`. `' Freie Universitaet Berlin - firstname.lastname@example.org
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913