Quoting Otto Kekäläinen (2024-08-03 06:38:38) > > I am not suggesting salsa use because I think it's the best thing since the > > invention of sliced bread. But personally, I rather use something > > suboptimal if > > it means that we can more or less agree on a "default" and I think that the > > current situation (submission of patches by mail and the debian archive is > > the > > bts) is deterring to newcomers. I know that most people probably have faster > > machines than I. As it was pointed out elsewhere in this thread, Debian > > work > > already implies a lot more waiting than "a few seconds" for salsa to finish > > loading a page or finish yet another animation, so meh. With the glab tool I > > think I can be happy enough. > > This I think summarizes well the opinion of most people I have spoken > with. GitLab is not perfect, but it was chosen and we have been using > it for 5+ years mostly successfully. Most packages are there and we > should state that it is the recommended option. Currently the second > most popular option is to use GitHub, or not use any vcs at all. > > A lot of this thread has gone into people expressing their dislike for > Salsa. Most people still use Salsa - I guess the silent mass isn't > chiming in in this thread that much now. Some people probably have > very optimized email workflows, and nobody can argue against the > statement that a pure email workflow for sure is simple, and has its > elegance. But it also has shortcomings such as no lack of > metadata/status, no built-in way to run CI and share the code+logs+CI > results etc. > > Following the principles 1 (use git) and 2 (use Salsa) allows for the > next principles 3, 4 and 5 to take place. I would be curious to hear > more views about them. > > DEP-18 summary (https://salsa.debian.org/dep-team/deps/-/merge_requests/8): > 1. Have package source code in version control, using git > 2. Host package source on Debian's code forge Salsa > 3. Run Salsa CI at least once before every upload to ensure minimal > level of quality > 4. Allow Merge Requests to be submitted > 5. Allow changes to be reviewed before uploads to Debian > > My plan is to summarize the discussion and update the proposal in the > coming days, incorporating as many views as possible. I will also in > the next update include additional relevant context info such as > tag2upload, glab and examples of how to easily work with both Debian > bug tracker and MRs in parallel. > > Please share your views, and also +1 or -1 the proposal on Salsa so we > can incorporate that too in measuring the support of this. > > Remember that DEPs are soft rules - unlike General Resolutions (GRs) - > and maintainers who have specific reasons to not want to use git or > Salsa will not be forced to do so.
My problem with DEP-18 is that people who have zero problem with using git and are also not fundamentally against using salsa, but have reservations surrounding *which parts* of salsa to use and the consequences for related already used tooling. I am also not against being welcoming to newcomers, but I am concerned if the focus on tose unreasonably reshapes the tooling for all of us. Essentially, my concern is that DEP-18 reduces a spectrum of options to "either you are for or against true collaboration". Leaning more on Gitlab is not the "true" choice, but the pragmatic one, because yes, we have invested in it, and some parts of it might be made to better use for use. I imagine that some in the silent crowd hesitate to chime in due to that lumping together the use of git and the use of Gitlab into an all-or-nothing choice. I think you intended that reduction, for the purpose of simplifying the conversation. I don't think that simplification is helpfull, however. - 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
