Hi, On Fri, 2 Aug 2024 at 16:27, Johannes Schauer Marin Rodrigues <jo...@debian.org> wrote: > Quoting Otto Kekäläinen (2024-08-02 17:23:51) > > I agree that Salsa is sometimes a bit sluggish > > (https://salsa.debian.org/salsa/support/-/issues/395), > > what kind of hardware do you have? For people like me who are on slower
I have a 4-year old Dell XPS 13 (that came with Ubuntu preinstalled and has perfect Linux support, great laptop by the way). > hardware, the web experience is absolutely not funny and "a bit sluggish" > doesn't begin to describe it. It is hard to find any other website I'm > visiting > that is slower than gitlab. For example, when I run this on my Firefox I get a > score of 1.53: https://browserbench.org/Speedometer3.0/#summary I got 9.25. Some of the GitLab slowness is due to the server side, and some due to JavaScript. I prefer to use mild terms "a bit sluggish" out of empathy to the people who maintain Salsa, as it is probably not fun for them to read too vocal complaints after the incredible amount of work they have put in to get us this far. I am very grateful for their work and with the language in the bug report I try to be constructive on what things to prioritize next. ... > You now said "I hope we can do something to improve it and it is now a > permanent reason to not use Salsa." twice: > > Did you typo it twice or do you actually mean that it's now a permanent reason > to not use salsa? Thanks for pointing out the typo. I meant 'not a permanent reason'. I typo now/not frequently for some odd reason and since both words are in the dictionary, my spell checker does not flag it. > 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.