Re: Debian Archive architecture removals
+++ Samuel Thibault [2015-05-05 09:17 +0200]:
> * Getting binNMUs from d-release transitions
>
> This saves porters a lot of tedious work that would otherwise be just
> duplicated. We are not talking about fine-grain binNMUs here, but
> coarse-grain well-known planned binNMUs. Wanna-build supports extra-deps
> which makes it easy for d-release to just throw them at debian-ports
> archs along the master archs and forget about it.
I would just like to second this point, having brought a port through
d-p recently. Keeping up with transition binNMUs is a quite a
significant overhead for a (usually small and overworked) porting
team. As a porter one has a good understanding of arch-specific
issues, but very little understanding of current archive-wide
transitions. And the existing infrastructure doesn't tell you that
things have been rebuilt in the main archive so you should do it too -
you have to poll (or notice when things break/become uninstallable).
It would certainly be an improvement if d-p architectures at least got
notice of such rebuilds (maybe this already could happen, I just
didn't know how?). It would be even better if they automatically
propagated (although this may sometimes break stuff, especially in
early life of a port - some trade-offs there).
> Those two previous items may actually perhaps be fixed together:
> could it make sense to have the debian-ports architectures on
> buildd.debian.org, would it bring human overhead? The databases there
> are already per-architecture, so they don't actually interfere.
That's a intresting possibility, but there are also advantages to the
current separate instance/database, config, authorisation and usage
expectations. Merging would fix this issue but might cause others - I
don't know enough to say.
> Perhaps we need a political decision here?
I think it's mostly a practical one, as I don't see much disagreement
about the objectives here: What is the best way to arrange things to
support 'released, supported, all-equal' ports vs 'best-effort, let
them get out of sync' 2nd-class ports (both on the way up ('upcoming')
and on the way down ('legacy')).
Centralise the things we can to take workload off porters, distribute
things where ports being broken or unloved could hold up the
released ports.
This is the sort of thing where getting the right people in a room is
productive as hardly anybody has a good overview of all the
aspects/issues. Debconf session?
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
Reply to: