On Sat, Mar 22, 2025 at 08:24:34AM +0100, Jonas Smedegaard wrote: > Some of us (me included) prefer Salsa over Github or Sourcehut or other > forges, but what we use is its git hosting service without its optional > web-centric services (regardless if accessed via a web browser or a web > CLI tool).
This applies to me as well. I absolutly prefer CLI, not web. That said,
I often checkout salsa's MR via "git mr origin 123" with these two lines
in my .gitconfig:
[alias]
mr = !sh -c \"git fetch $1 merge-requests/$2/head:mr-$1-$2 && git
checkout mr-$1-$2\" -
I also do comment on MRs and salsa issues via the webbrowser *and* via mail.
I also really dislike the salsa web ui. I really like salsa however.
> I don't see a conflict there. I was interested in collaboration before
> I learned to master git, and today I am interested in collaboration even
> if not the same kind of collaboration that some might take for granted
> as being the norm.
>
> The way you phrase it here - collaboration in 2025 without using *any*
> system for version control - I agree that it is difficult to not read
> some degree of conflict into that. But if instead saying collaboration
> in 2025 without playing into the norm of reducing the collaboration
> style to simple statements in the package control file, then I can
> easily imagine reasons for doing so that are not contradictory.
> Personally I have strongly considered *removing* the hinting that the
> packages that I maintain are version-controlled at Salsa, to avoid
> anyone making too much assumptions on *how* I make use of Salsa and
> therefore *which* kinds of collaboration I "obviously" am doing - and
> I then risk having an NMU done that was notified ahead but only via
> Salsa chatter which I don't follow.
>
> Yes, you do not need to tell me that I can just disable merge requests.
> I try to remember to do that - it is tedious, because they are enabled
> by default and it is a lot of webby clicks to disable. I have however
> experienced several times that others have then turn it on again, no
> doubt by the assumption that it was disabled in error - i.e. again
> assuming that collaboration on Salsa means collaboration the common
> Salsa way.
>
> I can see an efficiency benefit of streamlining towards one single way
> to do collaboration in Debian. I am not convinced that the efficiency
> is the only relevant quality in collaboration, however. And to me it
> feels like there is a movement towards reducing variety of methods which
> is driven by efficiency and does not care about other reasoning. As the
> dgit project has meticulously mapped, there are many ways to use git
> for Debian packaging, and on top of that there are several ways - not
> only in Debian but also in the wider hacker community - of how to
> collaborate around git. Some of us in Debian want to explore and
> experiment and learn, not just get things done.
I very much agree with these four paragraphs.
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄
"... the premise [is] that privacy is about hiding a wrong. It's not.
Privacy is an inherent human right, and a requirement for maintaining
the human condition with dignity and respect." (Bruce Schneier)
signature.asc
Description: PGP signature
