Hi! On Fri, 2 Aug 2024 at 02:27, Andrea Pappacoda <and...@pappacoda.it> wrote: .. > Before a certain way of doing things can be mandated or "warmly > recommended", the technology has to be as flawless as possible - and > today I wouldn't call Salsa "flawless", would you? Issues with > Salsa/GitLab: > > 1. It is so slow that it makes me want to close by browser and do > something else instead > 2. It doesn't support email-based workflows > 3. It has a lot of features we don't need. Or rather, it has more > features we *don't* need than we do. > 4. Its user interface is confusing, it's often hard to find what I'm > looking for > 5. Did I mention how slow it is? > 6. It is developed by a company who's philosophy and interests are > misaligned with Debian's > 7. The product it tries to mimic, GitHub, is also misaligned with > Debian's philosophy and interests > > While performance is something we could reasonably do something about, > all the other points are part of GitLab by design, and we're stuck with > them.
GitLab of course has more features than what we need; it does not mean it has to be used. The basic feature set in GitLab to browse repositories, show and compare history, show CI status, list MRs, separate drafts and ready ones, show approvals, show assignees etc work well. GitHub has done many things well and trying to compete with them is a good thing. Both GitLab and GitHub also support email workflows to some degree (but of course most people use them via the UI as the UI offers many things email does not and never will). I agree that Salsa is sometimes a bit sluggish (https://salsa.debian.org/salsa/support/-/issues/395), but I hope we can do something to improve it and it is now a permanent reason to not use Salsa. ... > But the point isn't that much about being able to use emails > specifically, it is about having the possibility of having a software > forge which is interoperable with a wide range of tools and can stay > out of the way if wanted. With GitLab, you either use the full package > (which includes browsing, reviewing, and commenting) or you get a > sub-optimal experience. But it doesn't have to be this way. > > I'll now talk a bit about SourceHut. Not to suggest that we should use > that instead, but just to point out how things *can* be done. I have a paid SourceHut account and have been testing it for some time. I can see the appeal of simplicity, but for actual team work it is *too* simple. It will probably take a couple of years for it to mature. Note that a DEP is not a vehicle to drive out new version control systems or source forges. It is a vehicle to formalize something that is already popular as an official best practice. The salsa.debian.org is what we have today, and Debian has been using for a 5+ years. If some day in the future something vastly superior to git or GitLab surfaces and a lot of people start using it, the DEP could be updated. But I would not today recommend new Debian maintainers to host on SourceHut nor GitHub nor self-host. They can mirror there if they want, but for collaboration prior to uploading to work well the source code should be on salsa.debian.org for now. When I today reviewed recent submissions on mentors.debian.net, most of them were hosted on Salsa, but 4 on GitHub and 1 in nowhere in git at all. As it currently stands, there is no official document I could lean on to ask the submitters to please use salsa.debian.org instead. This is one of the motivations for this DEP.
