Re: Debian Archive architecture removals
On Tue, May 5, 2015 at 3:17 PM, Samuel Thibault <sthibault@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/sthibault@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-hurd@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-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: [🔎] 20150505071702.GI3090@type.bordeaux.inria.fr">https://lists.debian.org/[🔎] 20150505071702.GI3090@type.bordeaux.inria.fr
>
--
bye,
pabs
https://wiki.debian.org/PaulWise
http://bonedaddy.net/pabs3/
http://wiki.openmoko.org/wiki/User:PaulWise
Reply to: