Hi, On 6/13/24 06:00, Luca Boccassi wrote:
Yes, that's the argument - all Salsa features are bad and "bloat": issues are bad, teams are bad, CIs are bad, merge requests are bad, the only thing needed is to push&pull to some git backend, everything else is bad and unneeded.
The requirements for the archive differ from and sometimes conflict with the requirements for collaborative packaging, which differ from and sometimes conflict with the requirements for regular development.
It is completely valid, and in my opinion also better, to deploy multiple targeted solutions in parallel and make them interface with each other than try to graft the missing use cases onto a 95% solution that is being built by an external party that has their own product road map which does not include these use cases.[1]
The archive does not need to keep the full collaboration history, for example -- in fact it is counterproductive, because the archive is being mirrored and archived, and we need to keep the size small.
The archive also has a strict requirement *never* to execute any code from uploaded packages on machines used in upload processing. From the point of view of the archive software, we are dealing with data only. This is a requirement salsa cannot ever fulfill.
In the reverse direction, that is also true: the archive maintenance software can not perform a CI build because the security posture it takes forbids it from doing so, so it can not replace salsa.
GitLab issues are missing the archive integration of the Debian BTS, and the tracking of issues forwarded to other bug trackers. Therefore, salsa cannot replace the Debian BTS for packaging work. We could try writing bots, but it would be a graft, not a targeted solution.
On the other hand, the Debian BTS does not have git integration, so I cannot refer to bugs from commits and track individual work items between releases this way -- it mainly provides an external view, and an interface for users, and is less useful for team-internal collaboration.
Again, we have two different use cases, and two different tools, and neither can replace the other. There is no working hierarchy in which one is objectively better than the other, because the measuring stick is fitness for a particular purpose.[1]
Simon [1] this applies to salsa and systemd.
