Quoting Otto Kekäläinen (2024-05-19 05:25:10) > In a recent long thread on debian-devel you had somewhat negative > sentiments towards the usefulness of Salsa. I do see you doing good > technical work for Debian and recently a MR from Bill too, so I was > thinking that maybe you will change your mind when you read more > in-depth arguments. This is my attempt to have you think about Salsa > in a new light: > > On Tue, 9 Apr 2024 at 11:41, Bill Allombert <ballo...@debian.org> wrote: > > Having a repository on salsa or even "packaging team" does not prevent > > a lack of maintainer, so this is not relevant. > > Without a maintainer, no contribution will be merged in any case. > > Consider this Merge Request to fix debbugs builds immediately, and to > include Salsa-CI to keep the build from regressing again: > https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 > > 1. If the package was not on git and Salsa, I would have no way to see > what the maintainers have been doing in the years 2018-2023 (Debian > repos had last upload in 2018)
With git (or another VCS) but *without Salsa, you would certainly not be blind to existing development. I agree with striving towards VCS tracking of all code in Debian, and striving towards the use of a single VCS, and I think it is reasonable to separate the discussion about that from the discussion about the relevancy of Salsa. > 2. If the package was not on Salsa, and had the MR feature active, I > would not be able to submit a MR to fix the issues. Now the MR is up > there, and anybody can review and comment it - thus we are not even > dependent on the original maintainers alone. With git but without Salsa, you would post a patch to Debbugs, that would be up there for anybody to review and comment on. Sure, you would not be able to specifically use a Gitlab routine without having a Gitlab instance to do it on. And reviewers and commenters would need to be bothered with using email, which is different but not inherently worse than having to be bothered with using Gitlab UIs. Did you also post your MR as a patch in Debbugs? > 3. The UI is easy and useful. I invite you to read my MR and add your > review. I made have some extra instructions to make this very > welcoming for people who do not "like" Salsa/GitLab and might feel > that something is unintuitive The UI of my email program is easy and useful. You don't need to agree with me, you can pick another email system that is more to your liking. It is much harder with Gitlab to provide room for different personal ways of working. Please note, that I am here, like yourself, not talking about different ways of structuring code in a VCS, but about how the UI affects how you personally are able to interact. You and I quite likely use different text editor, and different email application, and possibly also different web browser. That affects how easy and useful the personal end of collaboration is. The collective end of collaboration must involve how (if at all) code is tracked in a VCS, but it need not dictate UI at all. > 4. If you don't want to use the web UI, you can also download my patch > https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19.patch > and review by email. Or you can click in the UI once to subscribe the > MR and then continue review/comments by email. If you don't want to use a command-line or a scripted or a GUI-based email application for receiving patches shared at Debbugs, you can use a web-based email application - locally hosted or through a provider. I already subscribe to Debbugs for the packages and teams I am most interested in tracking contributions for. > Personally I fully agree with the people stating that "Salsa is the > best thing in Debian in the past 20 years". So far everyone I talked > to who initially had reservations regarding using Salsa have started > liking it after they learned a bit more how it works, and have seen > things like Salsa-CI in action saving the Debian archive from needless > widespread failures. Debian is *not* helped by spreading issue tracking across multiple independent data and communication networks. My concern about Gitlab is not its *additions* to existing services, but its *duplications* of core services already in Debian. Please, let us separately discuss if we should... * mandate VCS-tracking * mandate the use of one specific VCS * mandate one specific VCS workflow * mandate collaborative packaging * mandate project-wide issue tracking * mandate a single project-wide issue-tracker ...instead of lumping all those discussions into a discussion of ease of user interface for a single catch-all code forge that maybe make all those other complications go away by affecting all those questions and that way implicitly provides *some* answer to them all. Personally, my current opinion on each of the above is this: * mandate VCS-tracking * Yes * mandate the use of one specific VCS * Yes: git * mandate one specific VCS workflow * Not yet, but require unusual workflow flagged and documented * mandate collaborative packaging * Not yet, but * mandate project-wide issue tracking * Yes: personal/team issues like WNPP work are project issues * mandate a single project-wide issue-tracker * Yes: Debbugs (for now: open to switch but not to duplicate) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
