On Tue, May 5, 2015 at 3:17 PM, Samuel Thibault <sthiba...@debian.org> wrote: > [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 >
-- bye, pabs https://wiki.debian.org/PaulWise http://bonedaddy.net/pabs3/ http://wiki.openmoko.org/wiki/User:PaulWise -- 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/caktje6gqt+y50wi4_d-5gzpvd2c+smr3qpgro8fid_qo2ct...@mail.gmail.com