[ With my debian-ports admin hat ] On 2015-05-04 11:48, Cyril Brulebois wrote: > Lucas Nussbaum <lucas@debian.org> (2015-05-04): > > I'm wondering if we could find a way to accomodate those architectures > > in an official way, while still limiting the impact on ftpmasters and > > other teams. I'm not entirely clear on the status of debian-ports.org, First of all it should be noted that moving an architecture to debian-ports, while decreasing the load on ftpmasters, increases the load on debian-ports, so it doesn't change a lot for the project. In practice it even increases as you need more manpower to maintain an architecture in debian-ports than in the debian archive. That's why we should move an architecture to debian-ports only if it some people (DD or not) are really going to maintain it. If not we already have snapshot.debian.org for that. > > and of what the current downsides of using debian-ports are. 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. > > Last I heard about it, it was understaffed and infra was undersized + > needed some changes to make it possible to grow. The situation hasn't really changed. Currently the whole debian-ports runs on a single machine, which is a VM kindly provided by DSA. This means running the archive (mini-dak) with http/ftp/rsync, buildd, cdimage and a few more services on a single machine. The machine is therefore heavily loaded, especially I/O wise and we had to disable rsync access except for a few mirrors working in push mode (so that we can control when they do the sync, ie not during mini-dinstall). On the manpower side we are also clearly understaffed, and only working in emergency mode when something is broken. For example the wanna-build installation is usually lacking months of commits compared to the official one. We tried to start addressing with a "plan" to move services to DSA administrated machine, as it can be seen there: [1]. We started by moving easy things like DNS and website. We then continued by moving the buildd service to a new machine called portman.d.o mimicking as much as possible the layout of the buildd.d.o installation, but we failed to do so in reasonable time. The main issue there is than buildd is a HUGE PAIN to setup as it is actually composed of wanna-build + wbpy + pgstatus + some additional scripts. Add to that some uncommitted code and code running in some $HOME... In addition to that it requires a lot specific setup as root, and thus interaction with DSA. We therefore decided to continue on that at Debconf 15 during a more general sprint [2]. After that we still haven't agreed on how to give access to non-DD people to a DSA administrated machine (see below why I believe it's important). We have some ideas about how to handle the remaining services but no real plan so far. Any help would be appreciated for the move, but also for longterm administration. Of course only serious help, not just unknown persons wanted to be root on debian-ports (yes we get this kind of offer from time to time). > > What > > are the current downsides of moving hurd-i386 and sparc to debian-ports? First of all we roughly have two kind of architectures on debian-ports: new architectures which are there for a short time until they get accepted as an official architecture and previously official architectures coming there to die on the longterm. debian-ports has been designed for the first case, where there is usually a lot of manpower. The second case is a bit more recent and started with the removal of official architectures from Debian. I see the following downsides in using debian-ports for an architecture, but they are likely a lot more: - debian-ports uses mini-dak instead of dak. It uses less resources and brings some features that are useful for new architectures like accepting binary uploads when it "improves" the version even if it is not the latest one or an "unreleased" suite for packages built from modified source (hence architecture specific). On the contrary its biggest issue is that it is source package based, which means if a package is renamed in a transition this causes the old binary package to disappear and the new one to appear. This causes a lot of extra work for transitions. - Build daemons are not "owned" by Debian, but have to be provided, hosted and administrated by individuals. It means the machine usually sits on DSL line behind a NAT, that's the reason why debian-ports also provide POP3 mailboxes (yes wanna-build partly communicates by mail). - The above is also true for porter boxes. - Given the above and due to the lack of manpower, more "broken time" than the official archive. - Transitions are not handled by the release team. - Bug reports concerning these architectures are more often ignored, even if they contain a patch. In addition to that I would like to remind that half of the people actually using debian-ports are non-DD, and I really believe we should keep giving them access. This is something even more important if we use debian-ports to host architectures failing to get enough DD to stay as an official architecture. alpha and, to a lesser extent, hppa are good examples. They are in a better state now they are handled by non-DD than when they were in the official archive. If we want debian-ports to become an official service for SCC architectures, we therefore have to be able to give accounts on a DSA administrated machine to non-DD, and the same way to accept autosigning on buildds which are not administrated by DSA and not even by a DD. We even have to consider emulated build daemons. Aurelien [1] https://titanpad.com/debian-ports [2] https://wiki.debian.org/Sprints/2015/DebCampAutobuildersSprint -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net
Attachment:
signature.asc
Description: Digital signature