On Mon, Jan 24, 2022 at 10:31:01AM +0100, Sébastien Delafond wrote: > > As part of an upcoming survey that we are preparing, we plan to ask > Debian developers to rank, by order of importance, the most popular > ideas of improvements for Debian. > > That's where you come into play: it would be nice if you could share > what are — according to you — the most important projects/improvements > that Debian ought to make. You can share your ideas here by replying to > this email, but it would be interesting to file them as new issues in > the "grow-your-ideas" project and then reply here pointing to your new > issue:
I have raised https://salsa.debian.org/debian/grow-your-ideas/-/issues/15 # The problem If I had a magic wand, I would like to resolve the situation around official instances of packaged servers being unable to dogfood their packaging work. I think this sends the wrong message as "If it's not good enough for Debian to use, why should I?". # Actual situation From what I've noticed in DebConf talks, it's explained by the fact the service maintainers do not have root access on DSA machines. This leads to either using upstream installation methods or deploying to non-DSA machines. It seems to me that this is either a solved problem, or can be made so, given it's similar to University provided computing resources. # Expected situation For (a simplified) example that I'm familiar with, matrix.debian.social should be as trivial as `apt install matrix-synapse` plus a config file. Going by the existing docs on apache vhosts and email, one possible interface would be: echo matrix-synapse >> /srv/foo.debian.org/packages/install vi /srv/foo.debian.org/packages/etc/matrix-synapse/conf.d/social.yaml sudo -u foo package-setup foo.debian.org The permitted packages and config paths could even be managed by a whitelist under the control of DSA to prevent a complete wildwest. The important thing is that a service owner can make (certain) direct changes without having to co-ordinate DSA approval. # Additional information I first wrote directly to debian-admin but that list isn't publicly archived, so I'll only paraphrase the response I got: * Installation + configuration can have a risk of privilege escalation * DSA might be happy with MRs to the puppet setup for the simple cases * There is no external testing on the current puppet code, holding back collaboration by non-DSA * There have been small experiments with containerisation (IMO, that's abandoning the strength of Debian's *integration*)
signature.asc
Description: PGP signature
