Hello, I am mostly a the periphery of Debian for Debian Med, but at times this makes me add build dependencies that are of interest for everyone. Like, basic packages for nim. :o) Whenever we go out to the world we keep stressing that Debian Med is not separate from Debian at all. It is just the name of a community. With today's unbearable load for the FTP masters maybe we have to reconsider - after all, the FTP masters only see a fraction of what we really need in the distribution to solve today's biological challenges.
If we had another kind of repository for Debian Med, then quite a bunch of packages would not require the immediate scrutiny of our FTP masters. Frankly, most of our users will just accept that some upstream developer in github decided their software to be free and redistributable and don't look much deeper - they have a biological problem to solve and that package is part of a workflow that is today's best practice they want to follow. This pragmatic stance has been taken by conda and while our scrutiny is much accepted and praised in the scientific community, our packaging falls behind in both scientific coverage and adoption rate. The packaging of conda is not completely different from what Debian is doing, but conda is much more community-driven. Since conda started wit github, they basically had a salsa.d.o from day one. And they use it much to its full potential: automated updates, community peer reviews, very fast integration of new software. Two years ago we had first developers halting their contribution to Debian since from a biology-driven perspective, they cannot afford that extra effort since the advent of conda. Conda folks suggest that Debian should concentrate on the basic OS. And they have a point, especially since Conda gets increasingly close to what Debian is offering, e.g. with respect to CI. We cannot immediately adopt how conda is doing it since we would lose what makes us special. But we can learn and could imho fairly easily rewire Debian's package flow to make being an FTP master fun again. And at the same time speed up the periphery. Suggestions: * the periphery gets their own repositories - happily also called "channel" in analogy to conda * maintainer decides on what packages are auto-update-able within the channel by routine-updates (referencing a script by <tille>) * channel-community upvotes the integration of packages with Debian proper as a suggestion for FTPmasters * popcon gives feedback on the adoption of packages * FTPmasters pick new packages from the periphery channels as they see fit I am not sure about the granularity of these channels. Maybe every blend should have one or two channels. Obvious (to me) candidates: * med * astro * science * r * machine learning * <various packaging teams on salsa> To increase security especially when embracing new contributors without sponsors, I am tempted to say that we should not keep the sources in the git repository but analogously also to OpenWrt only maintain the debian folder. I find this to work amazingly well. We had discussed PPAs in the past - this suggestion is admittedly similar. The interaction with salsa and ftpmasters is what renders it most different, I tend to think. It is not an issue only of Debian Med - the packages are too much interconnected, I think. The packages that have most reverse dependencies to packages of many channels are the ones that the FTPmasters may want to prioritize. Steffen
