using salsa as a package triage system? "channels"?
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
Reply to: