On Wed, Apr 09, 2025 at 09:35:52AM +0200, Lucas Nussbaum wrote: > > First things first: the debuginfod.debian.net service exists since > > February 2021. I sent an email to debian-devel-announce[1], posted > > about it on my blog (which is syndicated on planet.debian.org) a few > > times[2], did a few presentations during DebConfs about it[3][4], and > > more often than not I talk to people about the service and let them > > know. > > > > Yes, I am a Debian Developer, and yes, this service runs on > > Debian-sponsored infrastructure. Right after I put the service online I > > reached out to DSA and expressed my desire to run the service on > > official infrastructure. I only received an official reply from the > > team a few months ago. I still have to sit down and follow up on that. > > I think that a more general question (for prospective DPLs) is how to > manage Debian services. The current state of things is (TTBOMK): > > 1/ There are some official Debian services, on the debian.org domain, > running on machines admined by DSA. DSA does some gatekeeping to ensure > that official services remain maintainable. I think that at some point, > there was a list of criterias for such services, but I can't find it > anymore. That list included stuff like redundancy regarding service > owners. Also, there was a list of official services and how they match > the criterias, but I also can't find it anymore (maybe I only dreamt of > both?)
I also wished we would be able to re-evaluate services, but that basically never happens. I had to pull the plug on a service recently by just making a decision on my own. So far we have not received a single complaint. But we have services that the world relies on that are effectively unmaintained. For internal services I am somewhat less concerned. For externally visible services I think we need to be more explicit about our commitments as a project. > 2/ There are also semi-official services hosted under the debian.net > domain. They are set up in a completely bottom-up way, without any > interaction with DSA. They are rarely co-maintained, and are thus quite > sensitive to the bus factor. > > Since it's easy to set up debian.net services, and *necessarily* a bit > painful and time-consuming to go through the steps required for turning > a service into a .debian.org service, there are some unofficial services > that remain unofficial but should really be turned into official > services. In this case this service started out contentious because mirroring of -debug happened without any ratelimiting in a way that kept DSA busy - instead of working with us and the mirror team to ensure that the goal is met. I asked some simple questions back in December on [1] to show that we are willing to help out here. As Sergio admitted there was no followup. > On the other hand, making it easier to experiment with unofficial > services could also be great. This could include making infrastructure > available for those experiments (such as cloud resources, as mentioned > elsewhere). > > Also, from the outside, it looks like DSA already has its plate quite > full, and could use some help with maintaining its current perimeter. I think we have a conceptual issue where Debian is becoming more and more difficult to keep as an underlying layer for services that are barely maintained - and then DSA ends up as the backup service maintainer. I would really want a container layer at this point to decouple the host from the services - a lot of the upgrade woes we had recently were not due to DSA, but due us being unable to get service owners to be available for the system upgrade. But this will take some time to get right. Kind regards Philipp Kern [1] https://rt.debian.org/Ticket/Display.html?id=8529
