Hi Otto, and all the others participating in this thread :)
Il giorno sab 27 lug 2024 alle 15:38:40 -07:00:00, Otto Kekäläinen
<o...@debian.org> ha scritto:
I have drafted a new DEP at
https://salsa.debian.org/dep-team/deps/-/merge_requests/8 titled
"DEP-18: Enable true open collaboration on all Debian packages".
Thanks for your work on this. Trying to unify aspects of Debian
development is one of the things I think we need to do to not only
"enable true open collaboration", but also to attract more new
contributors.
While the proposal has good intentions and goals I agree with, it tries
to achieve it with tools which, to my eyes, don't really enable "true"
open collaboration, which Jonas has expressed really well already.
The issue to me is when you add the word "Salsa", or more precisely
"GitLab" to the mix. Don't get me wrong: these days development *has*
to be done with Git and with CI workflows, but having to use GitLab
just to have these two things is overkill.
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.
It has also been mentioned that email-based workflows are for
"dinosaurs". Well, I'm 21, so I'm a living example that that's not
necessarily true :)
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.
1. It is really lightweight
2. It places emphasis on email-based workflows, while also providing a
web interface which can be used to view and interact with email
submissions.
3. It is modular. If you don't want the mailing list manager or the
issue tracker you can simply not install them.
4. The web interface exposes few things, maybe even too little
5. Yes, it's fast
6. Its developers truly value software freedom, just like Debian does
7. It tries to offer an independent product, without following GitHub's
lead
Since I'm lucky enough to still go to university, I conducted some
small scale experiment with a handful of students which were new to
software development. For their first Git group project, I let them use
SourceHut instead of GitHub, to see how accessible SourceHut was to new
users. They've been able to use it without issues, and I was happy.
Some time after this, they also had the opportunity of using GitHub,
which is not a surprise given its dominant position. The interesting
part though is that these students, when starting a new personal
project, chose to use SourceHut even if they also knew GitHub. They
found it more usable!
In conclusion, I think we should aim at providing a set of tools which
provides a "normalized view/workflow" which anyone can use, while also
giving the possibility to individuals to use their own preferred
personal workflow for their own work. GitLab provides this normalized
workflow, but by making it the only viable option. Just like how dgit
provides a canonical "dgit view" while letting maintainers user their
own packaging workflow, an ideal Debian code forge would provide, for
example, a canonical web UI which can also be interacted with by
email/command line, just like the rest of Debian's infrastructure.
I would've liked to provide concrete solutions, but for now I'll limit
myself at exposing problems :)
Bye!
