Re: using salsa as a package triage system? "channels"?
Hi Steffen,
I still don't quite understand the proposed idea. Is it something like
the Debian version of Gentoo overlay? My suggestion is that you should
make this proposal more specific, e.g. by shedding some light on the
way of implementing it.
Unlike the other distros, as you must have noticed, the human cost per
package for debian is significantly higher than that for other distros
-- an Archlinux developer may update thousands of packages a day, but
for me (Debian) 10 packages per day is already lots of work.
That means third-party package channels will inherit the same cost per
package, even if such cost can be reduced by doing something unelegant.
In this direction I proposed DUPR in the past and provided an unelegant
demonstration implementation.
We also have some similar historical proposals, such as the Debian PPA
as you said, and the bikeshed (I don't know who named it but please
rename it for good wish).
On Sun, Mar 15, 2020 at 04:22:47PM +0100, Steffen Möller wrote:
> 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.
Sometimes you can tell FTP masters the important things via the
"Comments:" field in d/copyright as long as appropriate. FTP masters
and trainees won't skip this field.
> 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.
Traditional packaging is lagging behind, or cannot even satisfy the user
demand. But that's exactly why business companies like anaconda exists.
As discussed before, I think we such a traditional distribution cannot
easily solve the problems that anaconda is trying to solve.
> 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.
I fully agree with conda folks that Debian should concentrate on the
basic OS, providing a solid base system for whoever the end user is.
Although one could have much fun working on low-popcon packages, but
the fact that "there won't be too many end users" is already
demotivating enough from time to time.
> 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
This part looks obscure to me. Could you provide more specific details?
> 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>
This indeed sounds like Gentoo overlay. I like gentoo overlay.
I also fancy gentoo features that Debian doesn't have.
> 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.
Such priority value can be calculated, say, by counting the number of
reverse dependencies. Someone interested in this could try to implement
this feature in dak and the FTP team will see this hint and tell the
priorities.
Reply to: