[Speaking for the debian-hurd team] Lucas Nussbaum, le Mon 04 May 2015 08:28:22 +0200, a écrit : > Maybe it's just about supporting and advertising debian-ports as > Debian's official way to host second-class architectures. Maybe > there's more to it. What are the current downsides of moving hurd-i386 > and sparc to debian-ports?
That's perhaps the best question to address. Being on master just for being mirrored is not useful to such kinds of ports of course. In the current status of the Debian infrastructure, there are however a lot more consequences, which we can perhaps work on, so as to avoid making hurd-i386 and sparc essentially disappear, and perhaps at the same time to revive some debian-ports archs without overhead for ftp-master, d-release etc.. Also perhaps more easily consider removing more archs from master. * Appearing on packages' and maintainers' PTS pages like http://buildd.debian.org/bash and https://buildd.debian.org/sthiba...@debian.org This makes people aware of portability issues; when hurd-i386 moved there some years ago, that did make a change: we saw maintainers caring and fixing their packages, quite often the fixes are quite trivial. It would be useful to see other debian-ports results there for portability checking, notably hppa. There is already a link to buildd.debian-ports.org, but people do not even notice it, let alone think about checking it. * 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. 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. * 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. * Being considered as "second-class citizen" Well, this is already rather true for hurd-i386: we do sometimes get answers from maintainers "this is not going to be a release architecture, I will not bother with patches for it" (even about packaging patches). Or the patches linger on the BTS for years (see https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-h...@lists.debian.org;tag=hurd) Currently we use the "important" severity for hurd-i386, but maintainers can just discard it. Being on debian-ports actually somehow partly helps here, since we can upload patched packages in "unreleased" and continue porting. But on the other hand this makes us less pushy, and patches tend to accumulate. Also, being on debian-ports makes it much more difficult to afford making binNMUs, and thus the patches can really linger in the BTS ad æternam. Perhaps we need a political decision here? Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150505071702.gi3...@type.bordeaux.inria.fr
