Re: Re-evaluating architecture inclusion in unstable/experimental

[Aurelien Jarno <aurelien@aurel32.net>]

Hi,

With my debian-ports hat on, let me answer the parts related to that.

First of all as a reminder, debian-ports was originally just there to
help bootstrapping an architecture and prove it meets the ftpmasters
criteria to become an official architecture. It has been used that way
for example for armel, armhf, arm64, kfreebsd-amd64, kfreebsd-i386 and
s390x.

On 2018-09-02 15:21, Samuel Thibault wrote:
> Hello,
> 
> Luke W Faraone, le lun. 27 août 2018 00:33:58 -0700, a ecrit:
> > So, in the first instance, would you like to continue being part of
> > unstable/experimental?
> 
> Well, I can simply point at what we said last time (IIRC) the question
> was raised, here are the importants point we see in being on debian
> instead of debian-ports:
> 
> https://lists.debian.org/debian-devel/2015/05/msg00070.html
> 
> 
> Samuel Thibault wrote for the debian-hurd team:
> > * Appearing on packages' and maintainers' PTS
> > pages like http://buildd.debian.org/bash and
> > https://buildd.debian.org/sthibault@debian.org
> 
> This has been changed since then: debian-ports architectures show up
> there.

Yes both instances have been merged during Debconf 15.
 
> > * Getting binNMUs from d-release transitions
> 
> I believe this is also now done for debian-ports architectures? This
> really saves a lot of duplicate work for porters.

For what I understand the release team schedule binNMUs on all
architectures that have the necessary packages built. As long as the
architecture is not lagging that should therefore be the case.

> > * Appearing on http://release.debian.org/transitions/ and
> > https://qa.debian.org/dose/debcheck/unstable_main/index.html
> > We're fine with d-release not looking at the hurd column. But *we*
> > however do look at it, and would be sad to completely lose that. It
> > could be in a completely separate page or column, that would not pose
> > problem.
> 
> I don't know if we have this for debian-ports?

debian-ports is only about hosting the archive, so we do not have that.
I guess that would need to be added the same way as for the buildd.d.o
merge.

[...]

> > 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.
> 
> Concerning mirroring, it is indeed useless to mirror hurd-i386
> worldwide. Considering maintenance burden, I'm a bit afraid of here
> simply moving the load from the ftpmaster team to the debian-ports
> ftpmaster team. I don't know the details, so can't say, I'm just Cc-ing
> both teams.

I agree for the mirroring part, that's why there are very few
debian-ports mirrors (the original plan was even to have none of them)
and that it is served through the deb.debian.org CDN.

Besides that mirroring aspect, I agree moving an architecture from
the official to the debian-ports archive is just moving the load to a
different set of Debian person and different set of Debian hardware.

Regards,
Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net