Il 02/08/2024 11:20, Andrea Pappacoda ha scritto:
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.
Having the packaging on git i think is very useful, whether it is on salsa or another system it would bring benefits to some packages not currently on git. Not to force to use it but at least recommend it (and then later reconsider whether to force it)
One particular thing noticed in some cases (and I hope they are not many) is the lack of use or especially updates of the Vcs-* fields in d/control. I think is important point to packaging repository from the tracker if present and to update it if moved, this can help collaboration and reduce possible waste of time doing things that are perhaps already done by others (or WIP) but which have not yet been uploaded.
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 instead2. It doesn't support email-based workflows3. 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 for5. 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 interestsWhile 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 :)
I think that both email and systems like salsa/github/gitlab etc. are useful, both with pros and cons. Forcing people to use only one or the other could be counterproductive at the moment. One thing that I think would be useful is to have certain, fast and simple information for each package about which actual collaboration methods it uses and prefers.
For example seeing a package it would be very useful to know immediately if it wants a collaboration only through bugtracker and patch, only through vcs or both are accepted. If managed in a team point more easily to information about the team and any pages with details (for example on wiki).
I mainly use salsa, it has many advantages and could bring improvements in many cases but as mentioned there are also disadvantages (partly subjective) and therefore forcing it I don't think is a good thing, rather recommending it instead.
But first of all I think it is essential to improve salsa performance and reduce downtime and problems. Over the last few years I have found myself too many times in cases where I could work on packages but salsa was not working or very slow, and many cases where I needed salsa-ci for quick checks but it had problems. This is discouraging for contributors and counterproductive (especially for those with little time available). Recently I think there has been some improvement compared to past periods when it was worse both with salsa speed/reachability and salsa-ci problems (which lasted longer), big thanks to all those who work on it to improve it and I hope it will improve further in the future.
Another thing that seems underestimated and I think it is good to emphasize is the excessive slowness of the wiki.debian.org, it seems much worse than salsa to me, and I think it's important to solve. There is a lot of useful (or in some cases essential) information on the wiki for developers (and also for users), and finding yourself too often when you need to read something there (or contribute to some page) that doesn't load or takes a very long time is counterproductive.
Trying to help new contributors by pointing them in many cases to information on the wiki and being told it doesn't load or is very slow is not good. And also for contributors who search for information by themselves and arrive at pages that they can't read at that moment or that take a long time is a risk to the growth of contributors and collaborations in Debian.
If someone thinks that these speed/reachabilityare not important because they are used to even longer times for many operations, for example regarding the bugtracker, tracker, upload etc., unfortunately we live in an increasingly frenetic and continuously worsening world (this world causes more and more stress and less and less time available).
And also another problem that I think is very relevant but underestimated,even if in general nowadaystalk a lot about simplifying and speeding up through technology I unfortunately in practicesee much more often that things gets complicated and with additions that are more of a burden than an advantage.
I therefore hope that any additions/modifications/obligations are evaluated well and in the most objective way possible. I think that participation in projects like Debian (and other open source projects) should be a satisfaction and a pleasure for those who participate and not an additional stress, this would bring greater results and benefits.
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 lightweight2. 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 does7. It tries to offer an independent product, without following GitHub's leadSince 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!
OpenPGP_signature.asc
Description: OpenPGP digital signature
