Let's make 2025 a year when code reviews became common in Debian

[Otto Kekäläinen]

Hi,

Numerous people are posting Merge Requests on Salsa. Please help review them!

There is no single dashboard to show all Merge Requests for all Debian
packages, but here are the largest teams listed to show how many they
have open (and total count in parentheses):

938 (9657) https://salsa.debian.org/groups/debian/-/merge_requests
91 (3058) at https://salsa.debian.org/groups/go-team/-/merge_requests
78 (2336) https://salsa.debian.org/groups/python-team/-/merge_requests
32 (1686) https://salsa.debian.org/groups/kernel-team/-/merge_requests
84 (1491) https://salsa.debian.org/groups/gnome-team/-/merge_requests
619 (1242) https://salsa.debian.org/groups/java-team/-/merge_requests
93 (980) https://salsa.debian.org/groups/multimedia-team/-/merge_requests
29 (964) https://salsa.debian.org/groups/rust-team/-/merge_requests
15 (882) https://salsa.debian.org/groups/DebianOnMobile-team/-/merge_requests
137 (761) https://salsa.debian.org/groups/installer-team/-/merge_requests
31 (725) https://salsa.debian.org/groups/games-team/-/merge_requests
24 (605) https://salsa.debian.org/groups/Mobian-team/-/merge_requests
15 (444) https://salsa.debian.org/groups/js-team/-/merge_requests
14 (343) https://salsa.debian.org/groups/libvirt-team/-/merge_requests
3 (282) https://salsa.debian.org/groups/med-team/-/merge_requests

If you have some spare time for Debian today, please consider
collaborating with another maintainer by providing them
review/feedback on an open Merge Request.

Some of them might be stale for various reasons, but there are for
sure many that are genuinely pending review/feedback. You don't need
to be a subject-matter expert. Any feedback is surely appreciated by
the author.

I hope more people do code reviews as I believe it can have these
benefits for Debian:
- Better social dynamics, fewer lonely maintainers and more collaborative spirit
- Better documentation of changes as authors write commit messages
thinking about the reviewers who will read them
- Higher average quality of changes (assuming Linus' Law)
- Hopefully higher quality also via CI results that integrate into the MR review
- Faster spread of best practices as more maintainers read code
written by multiple people in multiple packages
- More opportunities for new contributors to become active in Debian
as Merge Requests offer a easily relatable workflow to most software
developers


I personally feel strongly that code reviews and discussing optimal
solutions with other people makes Debian packaging way more fun than
simply working solo.

- Otto

[Chris Hofstaedtler]

Post by Otto Kekäläinen
Numerous people are posting Merge Requests on Salsa. Please help review them!
There is no single dashboard to show all Merge Requests for all Debian
packages, but here are the largest teams listed to show how many they
938 (9657) https://salsa.debian.org/groups/debian/-/merge_requests

[..]

Post by Otto Kekäläinen
If you have some spare time for Debian today, please consider
collaborating with another maintainer by providing them
review/feedback on an open Merge Request.

I gave this, specifically reviewing MRs in the debian namespace, a
try after your last message on this topic. Unfortunately I have to
say, it feels like a huge waste of time and is mostly frustrating.

I haven't noted down hard numbers, but my feeling is that 40%+ of the
MRs are from the janitor-bot, and mostly outdated. Anyone looking at
the list should immediately filter them out, because they are not
actionable in any way.

Then a lot of the MRs I looked at were "cleary good idea", but were
being ignored for _years_. I'm guessing this is because the
maintainer of the respective package is just AWOL, and we don't
have a process for dealing with that. In that case one can opt to
make their own life more miserable by doing a review, apply, test
build, test and "team upload", and at some point one will see the MR
submitter didn't bother testing the change.

The other big category of MRs in the debian namespace was and still
is: MRs where the maintainers don't get mails from salsa. If one is
active with the project, one can know who is currently around and
assign / ping them in the MR, and hope they'll respond after a few
days. The original submitter obviously is long gone, because these
MRs also sit there for years.

Another is MRs for packages that were removed from unstable a long
time ago. I've closed them when I encountered them, but did not file
a ticket to get the repo archived (*).

Having said that, my actions did get some MRs merged and a few
people were happy about that (thanks for the feedback!). But
overall, I still think it was a waste of time. The numbers are just
not in the favor of reviewers (and probably also not in favor of
maintainers).

Maybe a viable option for the debian namespace is to blanket close
any MR that is older than 6 months. But I don't know how that will
fare for the Janitor MRs.

Frustrated,
Chris


(*) there's a limit to "boring but someone needs to do it" where
I'll step in.

[Otto Kekäläinen]

Post by Chris Hofstaedtler

Post by Otto Kekäläinen
938 (9657) https://salsa.debian.org/groups/debian/-/merge_requests

[..]

Post by Otto Kekäläinen
If you have some spare time for Debian today, please consider
collaborating with another maintainer by providing them
review/feedback on an open Merge Request.

I gave this, specifically reviewing MRs in the debian namespace, a
try after your last message on this topic. Unfortunately I have to
say, it feels like a huge waste of time and is mostly frustrating.

Thanks! Seems we are now down to 838 open MRs in the Debian namespace.

Post by Chris Hofstaedtler
I haven't noted down hard numbers, but my feeling is that 40%+ of the
MRs are from the janitor-bot, and mostly outdated. Anyone looking at
the list should immediately filter them out, because they are not
actionable in any way.

I would recommend to just skip the janitor ones for now and focus on
providing feedback to humans to facilitate collaboration (among
humans).

Eventually the person making an upload of a package would be the best
person to merge/reject whatever janitor submitted ones are open.

Post by Chris Hofstaedtler
The other big category of MRs in the debian namespace was and still
is: MRs where the maintainers don't get mails from salsa. If one is
active with the project, one can know who is currently around and
assign / ping them in the MR, and hope they'll respond after a few
days. The original submitter obviously is long gone, because these
MRs also sit there for years.

I don't know exactly how Salsa is configured regarding notifications.
I agree it should be optimized but don't know exactly how.

Meanwhile, you can configure your own notification at
https://salsa.debian.org/-/profile/notifications and at least ensure
you are "watching" the pacakges you maintain.

Post by Chris Hofstaedtler
Another is MRs for packages that were removed from unstable a long
time ago. I've closed them when I encountered them, but did not file
a ticket to get the repo archived (*).

Thanks!

Post by Chris Hofstaedtler
Having said that, my actions did get some MRs merged and a few
people were happy about that (thanks for the feedback!). But
overall, I still think it was a waste of time. The numbers are just
not in the favor of reviewers (and probably also not in favor of
maintainers).

For sure, the first people going through the long list of pending MRs
will wade through a lot of accumulated cruft.

As a recurring MR review habit I'd expect people to only look at the
MRs that are recent and focus on them.

Post by Chris Hofstaedtler
Maybe a viable option for the debian namespace is to blanket close
any MR that is older than 6 months. But I don't know how that will
fare for the Janitor MRs.

I would not recommend doing any blanket close. I'd rather err on the
side of having some open in vain for a long time than throwing away
something useful. I think my personal record is a patch I sent to
Redis and it eventually got merged after being pending for 6 years.

However, I would support the idea of bulk closing MRs and complete
repositories *if* the package has been removed from Debian for the
same reason we bulk close their bug reports.

Post by Chris Hofstaedtler
Frustrated,
Chris

Thanks for your efforts! I think you can now with a good conscience
ignore old MRs and just focus on new ones next time you have time to
review.

The more DDs help with common namespace MR reviews, the less
frustrating it will be to individual DDs.

[Andrey Rakhmatullin]

Post by Otto Kekäläinen

Post by Chris Hofstaedtler
The other big category of MRs in the debian namespace was and still
is: MRs where the maintainers don't get mails from salsa. If one is
active with the project, one can know who is currently around and
assign / ping them in the MR, and hope they'll respond after a few
days. The original submitter obviously is long gone, because these
MRs also sit there for years.

I don't know exactly how Salsa is configured regarding notifications.

Opt-in.
See also https://salsa.debian.org/dep-team/deps/-/merge_requests/8#note_512610

[Andreas Tille]

Hi,

Post by Otto Kekäläinen

Post by Chris Hofstaedtler
I gave this, specifically reviewing MRs in the debian namespace, a
try after your last message on this topic. Unfortunately I have to
say, it feels like a huge waste of time and is mostly frustrating.

Thanks! Seems we are now down to 838 open MRs in the Debian namespace.

Nice.

Post by Otto Kekäläinen

Post by Chris Hofstaedtler
I haven't noted down hard numbers, but my feeling is that 40%+ of the
MRs are from the janitor-bot, and mostly outdated. Anyone looking at
the list should immediately filter them out, because they are not
actionable in any way.

I would recommend to just skip the janitor ones for now and focus on
providing feedback to humans to facilitate collaboration (among
humans).
Eventually the person making an upload of a package would be the best
person to merge/reject whatever janitor submitted ones are open.

Regarding Janitor: I admit I love these automated tools polishing
packages regarding so many issues reported by lintian and beyond. Its
really great and I really appreciate what Jelmer did. I use
lintian-brush (which is as far as I know the script behind janitor)
regularly (= a couple of times per day statistically). A big thank you
to Jelmer!

However, in all teams I'm deeply involved we asked Jelmer to not run
Janitor automatically on the Git repositories. The rationale is, that
if a package is not uploaded commits by the Janitor might become
outdated - well, finally what is described above is happening. We
simply run either lintian-brush (mostly triggered by routine-update
which included lintian-brush) right when working / before uploading a
package. This makes sure the package is polished *at the right time*.

I'm not sure if it is good that Janitor runs on Debian/ team packages if
it turns out that people do not care for those MRs created by Janitor.
Well, as far as I'm informed Janitor is not creating MRs any more but is
commiting directly so the non-human MRs will not be an issue any more
(Jelmer, please correct me if I'm wrong). However, if we have somehow
structured teams the way Janitor behaves can be written inside the team
policy where team members either like those commits or are running the
tools manually. For the Debian/ team I'm not really sure what might be
the best solution.

Post by Otto Kekäläinen
I don't know exactly how Salsa is configured regarding notifications.
I agree it should be optimized but don't know exactly how.
Meanwhile, you can configure your own notification at
https://salsa.debian.org/-/profile/notifications and at least ensure
you are "watching" the pacakges you maintain.

Thank you for the reminder. For my taste its suboptimal that users need
to actively switch on notifications but I'm aware that we have lots of
different tastes and it might make sense to stick to rather less than
more notifications default to not bother volunteers with to much
information. On the other hand this leads to the observed effect of
very many unattended MRs.

Post by Otto Kekäläinen

Post by Chris Hofstaedtler
Another is MRs for packages that were removed from unstable a long
time ago. I've closed them when I encountered them, but did not file
a ticket to get the repo archived (*).

Thanks!

+1

Regarding archiving the repo: In some teams this is done by moving the
repository to some folder named "attic" (or similar). I'm not sure
whether removed packages might consume a severe amount of disk space on
Salsa. IMHO having the repository around is rather a feature than a bug
so I'd tend to keep them even in case of removed packages.

Post by Otto Kekäläinen
However, I would support the idea of bulk closing MRs and complete
repositories *if* the package has been removed from Debian for the
same reason we bulk close their bug reports.

I tend to keep the repository for several reasons:
* Users might like to create their own local packages from the last
status of the repository.
* Vcs fields are published on lots of places and would become broken
links for no good reason.
* Someone might decided to re-introduce a package and likes to have
the history
* Repositories might be a great resource for "software-history"

What advantages would you see in removing repositories of removed
packages except saving some disk space?

Post by Otto Kekäläinen

Post by Chris Hofstaedtler
Frustrated,
Chris

Thank you for taking over frustrating work. Its really appreciated.

Kind regards
Andreas.

[Gioele Barabucci]

Post by Andreas Tille

Post by Otto Kekäläinen
However, I would support the idea of bulk closing MRs and complete
repositories *if* the package has been removed from Debian for the
same reason we bulk close their bug reports.

* Users might like to create their own local packages from the last
status of the repository.
* Vcs fields are published on lots of places and would become broken
links for no good reason.
* Someone might decided to re-introduce a package and likes to have
the history
* Repositories might be a great resource for "software-history"
What advantages would you see in removing repositories of removed
packages except saving some disk space?

Indeed, archiving the project [1], as suggested by Chris, seems a more
sensible course of action. Everything remains available, but users are
given a clear indication of the status of the repository.

[1]
https://docs.gitlab.com/ee/user/project/working_with_projects.html#archive-a-project

Regards,

[Andreas Tille]

Hi,

Post by Gioele Barabucci
Indeed, archiving the project [1], as suggested by Chris, seems a more
sensible course of action. Everything remains available, but users are given
a clear indication of the status of the repository.
[1] https://docs.gitlab.com/ee/user/project/working_with_projects.html#archive-a-project

Got it - shame on me that I was not aware and just thought we were
talking about moving to attic or something else. Just archived the
first batch of packages removed from Debian Med - will continue once
time permits.

Thank you for the hint
Andreas.

[gregor herrmann]

Post by Andreas Tille
However, in all teams I'm deeply involved we asked Jelmer to not run
Janitor automatically on the Git repositories. The rationale is, that
if a package is not uploaded commits by the Janitor might become
outdated - well, finally what is described above is happening. We
simply run either lintian-brush (mostly triggered by routine-update
which included lintian-brush) right when working / before uploading a
package. This makes sure the package is polished *at the right time*.

The alternative -- and that's what we did in pkg-perl -- is to have
the Janitor just commit to our repos instead of filing merge
requests:
https://salsa.debian.org/janitor-team/janitor.debian.net/-/blob/master/k8s/policy.conf#L357


Cheers,
gregor

[Andreas Tille]

Post by gregor herrmann
The alternative -- and that's what we did in pkg-perl -- is to have
the Janitor just commit to our repos instead of filing merge
https://salsa.debian.org/janitor-team/janitor.debian.net/-/blob/master/k8s/policy.conf#L357

I confirm I know this option. However, if Janitor changes from
debhelper compat 9 to 10, later from 10 to 11 etc. and the package is
not uploaded I fail to see the sense in accumulating changelog entries
which override themselves. Thus, as I said, I prefer running the
Janitor tools manually right when I intend to upload a package.

Thank you for the hint anyway
Andreas.

[Jonas Smedegaard]

Quoting Andreas Tille (2025-01-29 15:06:15)

Post by Andreas Tille

Post by gregor herrmann
The alternative -- and that's what we did in pkg-perl -- is to have
the Janitor just commit to our repos instead of filing merge
https://salsa.debian.org/janitor-team/janitor.debian.net/-/blob/master/k8s/policy.conf#L357

I confirm I know this option. However, if Janitor changes from
debhelper compat 9 to 10, later from 10 to 11 etc. and the package is
not uploaded I fail to see the sense in accumulating changelog entries
which override themselves. Thus, as I said, I prefer running the
Janitor tools manually right when I intend to upload a package.

git commit != changelog entry.

Please always proof-read changelogs before releasing a package, e.g. to
merge related git commits and drop notices for superfluous or reverted
changes.

- Jonas

[Julien Plissonneau Duquène]

Post by Chris Hofstaedtler
Maybe a viable option for the debian namespace is to blanket close
any MR that is older than 6 months. But I don't know how that will
fare for the Janitor MRs.

Given the "Debian time" scale, a much longer delay would be appropriate
IMO. I would suggest 2 years with no activity on the MR before closing
for "staleness", but ideally some data points should be extracted from
Salsa before discussing this.

Cheers,

[Julien Plissonneau Duquène]

Hi,

Post by Otto Kekäläinen
619 (1242) https://salsa.debian.org/groups/java-team/-/merge_requests

FWIW I took a look at that and most of them are Janitor merge requests.
Please just skip them as some are outdated, and I'm planning to take
care of them later this year with some housekeeping tasks.

Identifying merge requests that are clearly outdated and posting a
comment with a short explanation (e.g. "Obsolete MR: already fixed in
current package version") will also help in getting the count down.

Cheers,

[Andreas Tille]

Hi Gioele,

Post by Otto Kekäläinen
Numerous people are posting Merge Requests on Salsa. Please help review them!

Could we do the same for BTS patches?
There are ~5000 patches that have been sitting in the BTS for years, some
trivial (examples from my own: [1,2]),

To my experience from Bug of the Day there are lots of very obvious
patches and easy bugs. I fully agree with you that we have the
obligation to care for patches in BTS which is our prefered way to
report issues. As I wrote in previous mails I consider it worth
discussing how we can make this easier for developers who are not listed
as Maintainer / Uploader. Feel free to join the DebCamp project
suggested by Tobias Frost[3].

others less so. Most of the time they
are in the BTS because the associated packages have no Git/salsa repo.
https://bugs.debian.org/tag:patch

I'm not sure that these packages are on BTS only because the associated
packages have no Git/salsa repo. The BTS is our prefered form of
reporting issues. Adding an MR and linking to it as a patch as you did
in [1] is perfect and as a maintainer (who has all packages on Salsa)
I'm absolutely happy about this.

[1] https://bugs.debian.org/1051861

I've merged two of your gzip patches into the gzip repository. I also
upgraded debhelper compat level and Standards-Version for the kind
review of the maintainer (in BCC, since I know him personally I have no
doubt he will act soon). The repository is featuring the new upstream
version which IMHO is worth uploading to experimental. At least all
tests by Salsa CI are passing[4].

In principle I would tend to do a Debian/ team upload but I'm hesitating
for "Priority: required" packages. Thus pinging the maintainer. I will
tag the bugs closed by your MRs pending in a separate mail.

[2] https://bugs.debian.org/1057101

Its harder to do anything here. The package is actively maintained and
I would simply assume the maintainer (in BCC) has somewhere some Git
repository since this is the prefered way to maintain code these days.
It would be great to have packages of "Priority: required" on Salsa to
enable some team work on all our packages with high priority. This
might be some topic for the DebCamp project[3] as well.

Kind regards
Andreas.

[3] https://lists.debian.org/debian-devel/2025/01/msg00065.html
[4] https://salsa.debian.org/debian/gzip/-/pipelines/798305

[Andreas Tille]

Hi Gioele,

Please note that although the package has a repo on Salsa, MRs there
are/were explicitly disabled, at least for non-DDs (see the postscriptum in
[1], I see they are available now). Therefore were the commits in my
personal repo linked in the report in the BTS.

I guess this is due to some unfortunate default. MRs are possible now in
this repository.

Kind regards
Andreas.

[Matthew Vernon]

Hi,

Post by Otto Kekäläinen
Numerous people are posting Merge Requests on Salsa. Please help review them!

I'd much much rather MRs were associated with bug reports; that way I
only have to remember to check one place for outstanding issues in my
packages, and years down the line when I wonder "why did this change get
made" I can look up the bug report in the BTS.

Matthew

[Holger Levsen]

Post by Matthew Vernon
I'd much much rather MRs were associated with bug reports; that way I
only have to remember to check one place for outstanding issues in my
packages, and years down the line when I wonder "why did this change get
made" I can look up the bug report in the BTS.

+1
--
cheers,
Holger

⢀⣎⠟⠻⢶⣊⠀
⣟⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

Just because other people are also responsible, does not mean you are not
responsible.

[Gioele Barabucci]

Post by Matthew Vernon

Post by Otto Kekäläinen
Numerous people are posting Merge Requests on Salsa. Please help review them!

I'd much much rather MRs were associated with bug reports; that way I
only have to remember to check one place for outstanding issues in my
packages, and years down the line when I wonder "why did this change get
made" I can look up the bug report in the BTS.

Adding bug report numbers is simple if the MR fixes a reported problem.
For other improvements it's kind of cumbersome.

This is what I do:

1) I open a MR. As the description of the MR I use the message of the
commit, if it comprises one commit only, or the message of the main
commit (usually the first or the last one).

2) I open a bug report (tags + patch). The text of the report is the
description of the MR, plus a link to the MR.

3) I receive (some minutes later) a bug number.

4) I commit --ammend the main commit to add "Closes: #XXX" and
force-push it.

5) I add "(Closes: #XXX)" to the title of the MR.

I believe this is The Right Thing To Do™, but I really would like to not
have to do steps 2 to 5.

Perhaps it's time to have a mr2bts service similar to tag2upload?

Or forget about the BTS and accept Salsa as the main place where
improvements are discussed?

Regards

[Jonas Smedegaard]

Quoting Gioele Barabucci (2025-01-23 15:56:24)

Post by Gioele Barabucci

Post by Matthew Vernon

Post by Otto Kekäläinen
Numerous people are posting Merge Requests on Salsa. Please help review them!

I'd much much rather MRs were associated with bug reports; that way
I only have to remember to check one place for outstanding issues in
my packages, and years down the line when I wonder "why did this
change get made" I can look up the bug report in the BTS.

[...]

Post by Gioele Barabucci
Perhaps it's time to have a mr2bts service similar to tag2upload?
Or forget about the BTS and accept Salsa as the main place where
improvements are discussed?

Are discussions at Salsa preserved years down the line?

- Jonas

[Simon Josefsson]

Post by Jonas Smedegaard
Quoting Gioele Barabucci (2025-01-23 15:56:24)

Post by Gioele Barabucci

Post by Matthew Vernon

Post by Otto Kekäläinen
Numerous people are posting Merge Requests on Salsa. Please help review them!

I'd much much rather MRs were associated with bug reports; that way
I only have to remember to check one place for outstanding issues in
my packages, and years down the line when I wonder "why did this
change get made" I can look up the bug report in the BTS.

[...]

Post by Gioele Barabucci
Perhaps it's time to have a mr2bts service similar to tag2upload?
Or forget about the BTS and accept Salsa as the main place where
improvements are discussed?

Are discussions at Salsa preserved years down the line?

That is a good point. Are there any mirrors of Salsa at all? Having
continous replication to a couple of additional read-only instance would
be useful, in case Salsa burns up. How is the backup situation? What's
the restore process?

/Simon

[Philipp Kern]

Post by Simon Josefsson

Post by Jonas Smedegaard
Are discussions at Salsa preserved years down the line?

That is a good point. Are there any mirrors of Salsa at all? Having
continous replication to a couple of additional read-only instance would
be useful, in case Salsa burns up. How is the backup situation? What's
the restore process?

DSA is doing a daily file backup run using Bacula. PostgreSQL is
continuously streamed to the archive server and is probably 10 mins out
of date in the worst case - unless something breaks.

Kind regards
Philipp Kern

[Jonas Smedegaard]

Quoting Philipp Kern (2025-01-25 16:05:25)

Post by Philipp Kern

Post by Simon Josefsson

Post by Jonas Smedegaard
Are discussions at Salsa preserved years down the line?

That is a good point. Are there any mirrors of Salsa at all? Having
continous replication to a couple of additional read-only instance would
be useful, in case Salsa burns up. How is the backup situation? What's
the restore process?

DSA is doing a daily file backup run using Bacula. PostgreSQL is
continuously streamed to the archive server and is probably 10 mins out
of date in the worst case - unless something breaks.

Sorry if my question was unclear. I did not mean to ask for how long
administrators of Salsa would have access to their internally archived
data snapshots. Let me try again...

When I post to a discussion at Salsa, then for how long is my post
publicly available?

My guess is that my post disappears when the git-repo-project considers
the conversation obsolete (e.g. when a merge request is adopted or
dropped), and that backups from then on preserves the _removal_ of my
post, not the _existence_ of it.

The purpose of my question is to compare with mailinglists, where posts
are preserved "forever" (except corner-cases like spam and take-down
demands).

- Jonas

[Simon McVittie]

Post by Jonas Smedegaard
When I post to a discussion at Salsa, then for how long is my post
publicly available?

In general: until the project containing the discussion is deleted.

A "project" in Gitlab jargon is the thing that wraps a git repository;
more precisely it contains a git repository, an optional issue tracker,
an optional wiki, an optional container registry and so on, depending
which features were enabled by the project owner.

Archiving a project, which is what we (should) do with e.g. obsolete
packages that are removed from unstable, doesn't count as deletion:
your contributions to discussions in an archived project continue to be
part of that project.

(I assume the Salsa admins do have a way to permanently redact a
discussion thread that contains something illegal or abusive, if it
becomes necessary.)

Post by Jonas Smedegaard
My guess is that my post disappears when the git-repo-project considers
the conversation obsolete (e.g. when a merge request is adopted or
dropped)

This is not the case. For example,
https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/483 is
obsolete (in the sense that we merged the final version of the proposed
change), but my review comments on it remain, and so do the 4 older
versions of the MR that Paride pushed before we merged the 5th version.

Similarly,
https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/55 could
be considered obsolete (it was closed without being accepted) but you
can still read it.

Similarly,
https://salsa.debian.org/utopia-team/polkit-gnome/-/merge_requests/1,
https://salsa.debian.org/utopia-team/polkit-gnome/-/merge_requests/2 and
https://salsa.debian.org/utopia-team/polkit-gnome/-/merge_requests/4 are
merge requests to an obsolete (archived) project corresponding to a package
that we removed from unstable, representing all three possible states
(!1 was still open when the project was archived, !2 was accepted, and
!4 was rejected) and you can still read those too.

Issues behave similarly: you can still read
https://salsa.debian.org/ci-team/autopkgtest/-/issues/8 (which I filed
in the Salsa issue tracker instead of in the BTS, because there was never
an uploaded version of autopkgtest in the archive that had that bug: it
is a regression that only ever existed "upstream").

smcv

[Julien Plissonneau Duquène]

Post by Simon McVittie
(I assume the Salsa admins do have a way to permanently redact a
discussion thread that contains something illegal or abusive, if it
becomes necessary.)

It is also possible for the creator of a merge request (and probably for
the repository owners, and certainly for Salsa admins) to delete an
entire merge request. There is just a confirmation warning suggesting
other actions to avoid the loss of history. So by design this is not as
future-proof as public ML archives that are captured in the Wayback
Machine.

Another concern is that links to discussions may change, e.g. if the
repository is moved or renamed (not sure of what happens when the repo
is archived), or potentially with future releases of GitLab.

Yet another concern is that I don't think there is a way to split or
merge projects (or move issues and merge requests with their entire
discussion histories to other repositories). From experience, when this
happens most maintainers are not going to care anyway and will just mass
close issues and MRs.

Cheers,

[Julien Plissonneau Duquène]

Wayback Machine

FTR this project [1], according to this interview [2] (transcript [3]
search for "discussions") now aims to also archive the discussions
happening on merge requests and issues. So there is some hope for
future-proof archives and links of discussions on Salsa, which is
already captured by that project.

Cheers,


[1]: https://www.softwareheritage.org/
[2]:
https://hackaday.com/2025/01/22/floss-weekly-episode-817-incompatible-with-reality/#more-755972
[3]: https://flossweekly.libsyn.com/episode-817-transcript

[Otto Kekäläinen]

Hi,

Post by Jonas Smedegaard
Are discussions at Salsa preserved years down the line?

I don't think there is any special concern to suspect that Salsa or
any other official Debian service would seize to exist abruptly?
GitHub.com and GitLab.com has done a pretty good job at hosting
contents for years and years, hopefully Salsa can too. If another
service some day replaces it, I am confident that contents can be
migrated. We already successfully migrated git.debian.org to
salsa.debian.org.

Also note that the contents that really matter is the git repositories
themselves. The Merge Request feature is not intended to be a place of
permanent documentation. It is just a tool to facilitate fast and
accurate code review and efficient feedback among multiple
participants, and efficient publication and re-review of code. All
permanent documentation should to in inline comments, in READMEs in
the repository or when explaining specifically *why* a change was
made, it should be in the git commit message, and easily accessible
via git blame. If people have a need to read MR discussions, then the
git commit messages or git contents weren't done properly.

[Sam Hartman]

Otto> Hi,

Post by Jonas Smedegaard
Are discussions at Salsa preserved years down the line?

Otto> confident that contents can be migrated. We already
Otto> successfully migrated git.debian.org to salsa.debian.org.

Actually, I think this is a lot of the problem.
We did not migrate all the alioth content, only the repositories.
And so those of us who believe that content is important have already
been once burned.

Otto> Also note that the contents that really matter is the git
Otto> repositories themselves. The Merge Request feature is not
Otto> intended to be a place of permanent documentation.

Okay, but I want code reviews to be a place of permanent documentation.
I've had to do enough archaeology into why software decisions were made
over the years that I believe permanent documentation is critical in a
transparent project for anything along that path.
I've had to do so to look into how security problems arose as well as to
look into issues with network protocol interoperability.
The discussion of why decisions were made and what issues were raised at
the time can be really important.

I actually suspect that we would be able to preserve salsa merge request
discussions more easily than alioth content.
But if I were convinced that merge request discussions were not a
permanent form of documentation I'd close down merge requests on every
package I could and tell people to use the BTS.

[Julien Plissonneau Duquène]

Hi,

Post by Otto Kekäläinen
Also note that the contents that really matter is the git repositories
themselves.

I do not agree with this premise.

Post by Otto Kekäläinen
The Merge Request feature is not intended to be a place of
permanent documentation. It is just a tool to facilitate fast and
accurate code review and efficient feedback among multiple
participants, and efficient publication and re-review of code. All
permanent documentation should to in inline comments, in READMEs in
the repository or when explaining specifically *why* a change was
made, it should be in the git commit message, and easily accessible
via git blame.

This is true.

Post by Otto Kekäläinen
If people have a need to read MR discussions, then the
git commit messages or git contents weren't done properly.

I disagree with this conclusion. Sometimes features are extensively
discussed in salsa merge requests or issues, and the entire discussion
just can't be summarized in a git commit message (and it is not
desirable to even attempt that). This is especially true of features or
implementations that are abandoned (where there is finally no commit in
the project). Having access to these discussions is really useful when
picking up unfinished work, working on recurrent issues, or when trying
to find a new way to address something that was already attempted in the
past. Or just as a reference when explaining to somebody that something
is not a good idea.

Anyway I would trust the Debian Project and the Salsa admins to have
already realized that this history is just as important as the BTS
history, ML archives and other archives.

Cheers,

[Gioele Barabucci]

Post by Julien Plissonneau Duquène

Post by Otto Kekäläinen
Also note that the contents that really matter is the git repositories
themselves.

I do not agree with this premise.

The Git repo is forever and `git log` is how you search its history.
External websites will one day be gone. And are not accessible offline
("desert island" vibes here).

Post by Julien Plissonneau Duquène

Post by Otto Kekäläinen
If people have a need to read MR discussions, then the
git commit messages or git contents weren't done properly.

I disagree with this conclusion. Sometimes features are extensively
discussed in salsa merge requests or issues, and the entire discussion
just can't be summarized in a git commit message (and it is not
desirable to even attempt that).

True. This is why MR discussions should be automatically saved in git
notes attached to the merge commit. In this way the discussion will be
preserved and the Git repo will contain the whole development history,
freeing Debian from an eternal dependency on Salsa/GitLab.

Spending time writing the code that automates that is a much better
investment compared to copying stuff back and forth between
BTS/Salsa/mailing lists.

Regards,

[Julien Plissonneau Duquène]

Post by Gioele Barabucci

Post by Julien Plissonneau Duquène

Post by Otto Kekäläinen
Also note that the contents that really matter is the git
repositories
themselves.

I do not agree with this premise.

The Git repo is forever and `git log` is how you search its history.
External websites will one day be gone. And are not accessible offline
("desert island" vibes here).

The premise was ”the contents that really matter is the git repositories
themselves”. Where I disagree is that not ALL the contents that really
matters is in the git repositories, or even should be there, or even
could be there.

Post by Gioele Barabucci
True. This is why MR discussions should be automatically saved in git
notes attached to the merge commit. In this way the discussion will be
preserved and the Git repo will contain the whole development history,
freeing Debian from an eternal dependency on Salsa/GitLab.

In real life nobody does that. Among other issues, the discussion may
continue long after the commits are merged. Or the commits may end up
never be merged.

Post by Gioele Barabucci
Spending time writing the code that automates that is a much better
investment compared to copying stuff back and forth between
BTS/Salsa/mailing lists.

Something worth coding could be a service that uses salsa APIs to mirror
the contents of issues and MR discussions with URIs that are guaranteed
to be immutable (and JS entirely optional). That may help
archival/mirroring tools and AI t^H^H^H^H search engine indexation.

[Jeremy Stanley]

[...]

Post by Julien Plissonneau Duquène

Post by Gioele Barabucci
True. This is why MR discussions should be automatically saved in git
notes attached to the merge commit. In this way the discussion will be
preserved and the Git repo will contain the whole development history,
freeing Debian from an eternal dependency on Salsa/GitLab.

In real life nobody does that. Among other issues, the discussion may
continue long after the commits are merged. Or the commits may end up never
be merged.

[...]

Some code review systems do, in fact, store discussions, labels,
votes, prior revisions, and other metadata as git notes, named refs
and related objects. The notes are not frozen when a commit merges.
Up sides to this model mean you can back up and restore all of this
content just by copying repositories on disk, and highly-available
clustering can be implemented through git replication alone. I work
on some very large and long-lived projects that rely on one such
code review system, serving as one of its community sysadmins, and
it works remarkably well even if the vast majority of users have no
idea their discussions are actually being stored directly in git
repositories, to them it's merely an implementation detail.

But yes, it really needs to be a feature of the code review system,
not something managed by hand-editing notes objects; and as far as I
know GitLab does not do it, so this is not particularly relevant to
Debian while Salsa is running GitLab.

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Gioele Barabucci (2025-01-24 09:49:27)

Post by Gioele Barabucci

Post by Julien Plissonneau Duquène
I disagree with this conclusion. Sometimes features are extensively
discussed in salsa merge requests or issues, and the entire discussion just
can't be summarized in a git commit message (and it is not desirable to
even attempt that).

True. This is why MR discussions should be automatically saved in git
notes attached to the merge commit. In this way the discussion will be
preserved and the Git repo will contain the whole development history,
freeing Debian from an eternal dependency on Salsa/GitLab.
Spending time writing the code that automates that is a much better
investment compared to copying stuff back and forth between BTS/Salsa/mailing
lists.

this is the first time I hear about "git notes". I skimmed its man page.

But why a merge commit? I usually configure my salsa repos to *not* create
merge commits but instead rebase the MR on top of the target branch without an
extra commit on top.

I'm likely in lack of understanding here but I have not yet understood the
utility of merge commits. You say that they could be useful to attach git notes
to it. But can these notes not also attached to regular commits?

Thanks!

cheers, josch

[Gioele Barabucci]

Post by Johannes Schauer Marin Rodrigues
Quoting Gioele Barabucci (2025-01-24 09:49:27)

Post by Gioele Barabucci

Post by Julien Plissonneau Duquène
I disagree with this conclusion. Sometimes features are extensively
discussed in salsa merge requests or issues, and the entire discussion just
can't be summarized in a git commit message (and it is not desirable to
even attempt that).

True. This is why MR discussions should be automatically saved in git
notes attached to the merge commit. In this way the discussion will be
preserved and the Git repo will contain the whole development history,
freeing Debian from an eternal dependency on Salsa/GitLab.
Spending time writing the code that automates that is a much better
investment compared to copying stuff back and forth between BTS/Salsa/mailing
lists.
But why a merge commit? I usually configure my salsa repos to *not* create

merge commits but instead rebase the MR on top of the target branch without an
extra commit on top.

To use or not to use merge commits is a matter of taste and personal
preferences. My favorite combo is rebase + merge. In this way the
history is pretty much linear, but the merge commits clearly shows that
a bunch of commits belong together.

Post by Johannes Schauer Marin Rodrigues
I'm likely in lack of understanding here but I have not yet understood the
utility of merge commits. You say that they could be useful to attach git notes
to it. But can these notes not also attached to regular commits?

You can attach notes to any Git object, including regular commits.

Regards,

[Jonathan Dowland]

Post by Johannes Schauer Marin Rodrigues
I'm likely in lack of understanding here but I have not yet understood
the utility of merge commits. You say that they could be useful to
attach git notes to it. But can these notes not also attached to
regular commits?

Notes aside: with merge commits, in the future you can identify the set
of commits that belonged to the independent line of development that was
merged. That can be useful information, e.g., to figure out what commits
belonged to implementing a feature or fixing a particular bug.

When viewing or exploring a repository which has merge commits, if it's
your preference then (I think) one can generally hide them. But the
reverse isn't true: if the merge commit information is not in the
repository, then that information it is gone.

[Colin Watson]

Post by Gioele Barabucci
Or forget about the BTS and accept Salsa as the main place where
improvements are discussed?

As long as it's very commonly the case that nobody is actually
subscribed to merge requests on Salsa, it isn't realistic to expect
reviewers to only submit merge requests on Salsa in the general case
(outside of specific situations where you know that the maintaining team
uses Salsa actively for more than just git hosting). At least if you
file a bug then there's a good chance somebody will actually be told
about it.

[Wookey]

Post by Colin Watson

Post by Gioele Barabucci
Or forget about the BTS and accept Salsa as the main place where
improvements are discussed?

As long as it's very commonly the case that nobody is actually
subscribed to merge requests on Salsa, it isn't realistic to expect
reviewers to only submit merge requests on Salsa in the general case
(outside of specific situations where you know that the maintaining team
uses Salsa actively for more than just git hosting). At least if you
file a bug then there's a good chance somebody will actually be told
about it.

Right. I look at bug reports for my packages (eventually). I have
never looked at a Salsa merge request in my life. That's just
/dev/null for my packages. That could change one day, but I don't know when.

Wookey

[Otto Kekäläinen]

Hi,

On Thu, 23 Jan 2025 at 17:52, Wookey <***@wookware.org> wrote:
..

Post by Wookey
Right. I look at bug reports for my packages (eventually). I have
never looked at a Salsa merge request in my life. That's just
/dev/null for my packages. That could change one day, but I don't know when.

Could you give it a try please? Salsa isn't that bad :)

At https://qa.debian.org/developer.php?login=wookey%20%***@wookware.org%3E&comaint=yes
you can even see in the overview those 'Git #2 !11' and 'Git !1'
telling you there are two packages you maintain that have open MRs.

For example in https://salsa.debian.org/deeplearning-team/tensorflow/-/merge_requests/1
somebody contributed with packaging for binary package
'libtensorflowlite'. Reviewing and re-reviewing such work in a MR is
surely much easier than via bugs.debian.org. And there are cli tools
like salsa'[1] and glab[2] that can help you do some of the workflow
without a browser if you don't like web Uis.

[1] https://manpages.debian.org/unstable/devscripts/salsa.1.en.html
[2] https://manpages.debian.org/unstable/glab/glab.1.en.html

[Sam Hartman]

Otto> Hi,
Otto> On Thu, 23 Jan 2025 at 17:52, Wookey <***@wookware.org> wrote:
Otto> ..

Post by Wookey
Right. I look at bug reports for my packages (eventually). I have
never looked at a Salsa merge request in my life. That's just
/dev/null for my packages. That could change one day, but I don't know when.

Otto> Could you give it a try please? Salsa isn't that bad :)

Can you please respect people who have different positions than you?
I'm this close to turning off MRs for all my packages and promising to
be the last person in Debian who adopts any of the great work you are
doing, even though I think the approach you are taking would be a good
idea if successful.

The way in which you do not leave room for people who disagree with you
comes across as badgering and is something that I cannot bring myself to
support in our community.
Please be more respectful of others who have different workflows and
different ideas:

* Do not assert facts like "MRs don't need to be permanent
documentation." I would find your statements easier to support if
you said things like "MRs as permanent documentation is not important
to me," or "We can manage the risks of salsa going away by preserving
the information we need in commit messages."

* I would find your work easier to support if you worked with people who
have expressed openness and respected people who have already made a
different decision.

* Making claims like turning off MRs shows a maintainer is not
interested in collaboration. I could understand a claim like "Turning
off MRs will be perceived by many new contributors as a lack of
interest in collaboration." Clearly there are maintainers here who are
interested in collaboration and do want to receive patches through the
BTS. I think Asserting these people are not interested in collaboration is
dismissive of them, badgering, and in my mind borders on gaslighting.

* I think doing work to figure out which packages are open to MRs and
focusing on them is going to create a lot better experience for
contributors and maintainers than sending maintainers notifications
they are not going to read.

[Colin Watson]

Post by Sam Hartman
Otto> Could you give it a try please? Salsa isn't that bad :)
Can you please respect people who have different positions than you?
I'm this close to turning off MRs for all my packages and promising to
be the last person in Debian who adopts any of the great work you are
doing, even though I think the approach you are taking would be a good
idea if successful.
The way in which you do not leave room for people who disagree with you
comes across as badgering and is something that I cannot bring myself to
support in our community.

I agree with this. From Otto in another thread:

"It is sad to see that in Debian usage of git is stifled by simple
things like people not agreeing to use a common branch naming scheme
despite there being a proposal for 10+ years now."

I use git extensively for all Debian packaging work, but I find it hard
to bring myself to care about whether the default branch name is
consistent in every package I touch (it isn't, and I haven't been able
to observe any way in which it meaningfully affects either me or others,
so I'm not going to put energy into it when I could do something else
instead). To be told that this means I'm helping to stifle the use of
git in Debian is frankly infuriating and insulting.

[Holger Levsen]

Post by Colin Watson

Post by Sam Hartman
Otto> Could you give it a try please? Salsa isn't that bad :)
Can you please respect people who have different positions than you?
I'm this close to turning off MRs for all my packages and promising to
be the last person in Debian who adopts any of the great work you are
doing, even though I think the approach you are taking would be a good
idea if successful.
The way in which you do not leave room for people who disagree with you
comes across as badgering and is something that I cannot bring myself to
support in our community.

"It is sad to see that in Debian usage of git is stifled by simple
things like people not agreeing to use a common branch naming scheme
despite there being a proposal for 10+ years now."
I use git extensively for all Debian packaging work, but I find it hard
to bring myself to care about whether the default branch name is
consistent in every package I touch (it isn't, and I haven't been able
to observe any way in which it meaningfully affects either me or others,
so I'm not going to put energy into it when I could do something else
instead). To be told that this means I'm helping to stifle the use of
git in Debian is frankly infuriating and insulting.

💯%.
--
cheers,
Holger

⢀⣎⠟⠻⢶⣊⠀
⣟⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

“We live in capitalism. Its power seems inescapable. So did the divine right
of kings. Any human power can be resisted and changed by human beings.
Resistance and change often begin in art, and very often in our art, the art
of words.” ― Ursula K. Le Guin

[Gioele Barabucci]

Post by Colin Watson
"It is sad to see that in Debian usage of git is stifled by simple
things like people not agreeing to use a common branch naming scheme
despite there being a proposal for 10+ years now."
I use git extensively for all Debian packaging work, but I find it hard
to bring myself to care about whether the default branch name is
consistent in every package I touch (it isn't, and I haven't been able
to observe any way in which it meaningfully affects either me or others,
so I'm not going to put energy into it when I could do something else
instead). To be told that this means I'm helping to stifle the use of
git in Debian is frankly infuriating and insulting.

The idea here IMO is that heterogeneity (especially in what accounts as
a minor detail) leads to more complex workflows, workflows that cannot
be automated, and documentation that is longer or more complex than it
should be. This, in turn, stifles the use of Git/Salsa ("oh, too
complex, why should I bother?") and that, in turn, stifles the
recruitment of new people in Debian. It's not the people it's the workflow.

I personally experienced all this and I would agree that the negative
effects of not having a standardized Git-based workflow do exist.
Perhaps other people do not feel like that. But I believe (and I see in
#d-mentor) that there is a silent minority of people that got
discouraged due to exactly the above-reported issues.

Regards,

[Sam Hartman]

Post by Colin Watson
"It is sad to see that in Debian usage of git is stifled by
simple things like people not agreeing to use a common branch
naming scheme despite there being a proposal for 10+ years now."
I use git extensively for all Debian packaging work, but I find
it hard to bring myself to care about whether the default branch
name is consistent in every package I touch (it isn't, and I
haven't been able to observe any way in which it meaningfully
affects either me or others, so I'm not going to put energy into
it when I could do something else instead). To be told that this
means I'm helping to stifle the use of git in Debian is frankly
infuriating and insulting.

Gioele> The idea here IMO is that heterogeneity (especially in what
Gioele> accounts as a minor detail) leads to more complex workflows,
Gioele> workflows that cannot be automated, and documentation that
Gioele> is longer or more complex than it should be. This, in turn,
Gioele> stifles the use of Git/Salsa ("oh, too complex, why should I
Gioele> bother?") and that, in turn, stifles the recruitment of new
Gioele> people in Debian. It's not the people it's the workflow.

And reading your message, I do not feel fury.

I did not actually read that paragraph in the original message on my
first read through, but had I done so, I would have felt fury and my
response would have been less measured.
The way Otto phrased things, Colin and I both read judgment of the
people involved, not just judgment of the work flow.

There needs to be respect for people when they disagree. There needs to
be acknowledgment of the disagreement, not dismissing it. I do not feel
respected when I am told that if I just tried to use a certain workflow,
I'd like it.
People often do not feel respected when their trade offs about where to
balance their time are not given consideration.

I feel in some of these discussions like I am perceived as not good
enough if I do not cooperate with all of the different proposals
someone makes. I am asked to entirely adopt someone else's viewpoint.

In many cases I've considered that view and I agree with part of it.
And I feel like I'm challenged to accept the entire thing. If my choice
is all or nothing, my choice is going to be nothing---with a lot of
force behind that nothing.
But if I am given a choice in the middle then I will incrementally adopt
aspects.

In my particular case, I think a lot of these things have value as a
network effect.
The value in one person using the standardized branch name when no one
else does is zero.
The value in 1% of people using the standardized branch name is probably
also zero.
The value in 10% of people using the standardized branch name may be
significant if there are network effects among those people (for example
if they cover much of the membership of a given team).

You cross some threshold and the value starts to increase because other
people start to see that progress is possible and the rate of adoption
starts to increase.
It's not stifling to choose not to be an early adopter. It's not
stifling to actually look at things, conclude that the network effects
have not reached a point where it's worth your time to make a change.
Significant weight does need to be given to taking on some innovation
before it quite reaches the point of real returns: if no one adopts
early, the network effects will never build up.

Looking at the discussion of steps involved in changing a branch name,
I'm not eager to do that.
That looked like way too much work for the current return on investment.
If DEP 14 is accepted, I'll start using its branch layouts for new work.
If the tooling gets better such that I can `salsa rehead-from-to master
debian/latest` in one command then it would cross my personal return on
investment for existing repos after DEP 14 is accepted.

This is how change happens in a project like Debian.

And yes, some day, we may have strong enough community support behind
these proposals that the outliers need to either adopt the new standards
or leave, even if they don't see the value.
Ironically, I'd be less frustrated by a GR today than I am by the
(hopefully unintentially) dismissive language in the current discussion.
I don't mind having to change to be part of a community/team.
I do mind when my position/view is disregarded rather than being
considered and rejected.
I mind a lot when people assume I am stupid or have not done my homework
if I don't agree with them.

[Wookey]

Post by Otto Kekäläinen
Hi,
..

Post by Wookey
Right. I look at bug reports for my packages (eventually). I have
never looked at a Salsa merge request in my life. That's just
/dev/null for my packages. That could change one day, but I don't know when.

Could you give it a try please? Salsa isn't that bad :)

I have tried it. But it didn't give me anything I valued so after a
few months I went back to doing things the familiar way. I have put
some of my packages up there because others like it/git for
collaboration, but if it's just me I don't bother.

Some time when I'm not busy I'll investigate all these newfanlged
processes again, and have another go at all this stuff people keep
assuring me is 'better', but right now I don't have much time for
debian so using it to learn new stuff doesn't help get things done.

I'm quite happy with uscan, dch, patch-fettle, sbuild, sign, upload. I
know what to type. I know how it works. I know how to fix it if things
break and it doesn't take very long. If people send me bts patches
(and they do sometimes, which is great!) those are easy to apply too.

I just post to these threads occaisionally to remind you that people
happy with the existing stuff, and not rushing to change everything,
do stll exist :-)

Wookey

[Jonas Smedegaard]

Quoting Matthew Vernon (2025-01-23 15:28:00)

Post by Matthew Vernon

Post by Otto Kekäläinen
Numerous people are posting Merge Requests on Salsa. Please help review them!

I'd much much rather MRs were associated with bug reports; that way I
only have to remember to check one place for outstanding issues in my
packages, and years down the line when I wonder "why did this change get
made" I can look up the bug report in the BTS.

I wholeheartedly agree.

- Jonas

[Sam Hartman]

Jonas> Quoting Matthew Vernon (2025-01-23 15:28:00)

Post by Otto Kekäläinen

Post by Otto Kekäläinen
Numerous people are posting Merge Requests on Salsa. Please

help review them!
I'd much much rather MRs were associated with bug reports; that
way I only have to remember to check one place for outstanding
issues in my packages, and years down the line when I wonder "why
did this change get made" I can look up the bug report in the
BTS.

Jonas> I wholeheartedly agree.


I think it would improve collaboration a lot if we could make an effort
to get salsa projects into one of two states:

* Merge requests are disabled for that project

* Merge requests are actively watched at least as closely as the BTS

[Otto Kekäläinen]

Hi!

Post by Sam Hartman
I think it would improve collaboration a lot if we could make an effort
* Merge requests are disabled for that project
* Merge requests are actively watched at least as closely as the BTS

We should revisit the decision to have email notifications disabled by
default in all projects on Salsa. While anyone can enable
notifications for packages they maintain at
https://salsa.debian.org/-/profile/notifications, it would probably be
better if maintainers got notification emails by default from the
Salsa repositories hosting their packages.

I understand that some people like to turn of the MR feature
completely on their repositories, but I would advise against that, as
it is a major killer to collaboration. Not only does it signal to
contributors to the existing package that the maintainer is not
interested in spending time/effort on accepting contributions, but it
also makes it hard for abandoned packages to have spontaneous
collaboration arise and salvaging started as the potential
collaborators would never end up seeing each others MR submissions.

[Wookey]

Post by Otto Kekäläinen
I understand that some people like to turn of the MR feature
completely on their repositories, but I would advise against that, as
it is a major killer to collaboration. Not only does it signal to
contributors to the existing package that the maintainer is not
interested in spending time/effort on accepting contributions,

No - it just indicates that they want people to use the BTS or just
email. Contributions are always very welcome.

Wookey

[Xiyue Deng]

Hi Otto,

First I want to thank you for your work on Salsa. I find it pleasant to
use and the Salsa CI has also helped catch many lurking bugs for me.

Post by Otto Kekäläinen
...
I understand that some people like to turn of the MR feature
completely on their repositories, but I would advise against that, as
it is a major killer to collaboration. Not only does it signal to
contributors to the existing package that the maintainer is not
interested in spending time/effort on accepting contributions, but it
also makes it hard for abandoned packages to have spontaneous
collaboration arise and salvaging started as the potential
collaborators would never end up seeing each others MR submissions.

Actually there may be another reason to turn off MR feature: some
packaging workflows don't preserve a linear Git history and hence may
not work well with merging from MR on Salsa. For example, the "git-dpm"
and "git-debrebase" workflows, which use a more complex
merge/fast-forward strategy and merge requests don't integrate well. In
such case it's better to turn off MR to avoid any confusions and let
contributors post patches on BTS, and then the maintainer can apply
those accordingly.

[Colin Watson]

Post by Xiyue Deng
Actually there may be another reason to turn off MR feature: some
packaging workflows don't preserve a linear Git history and hence may
not work well with merging from MR on Salsa. For example, the "git-dpm"
and "git-debrebase" workflows, which use a more complex
merge/fast-forward strategy and merge requests don't integrate well. In
such case it's better to turn off MR to avoid any confusions and let
contributors post patches on BTS, and then the maintainer can apply
those accordingly.

I don't completely agree with the last part of this: I use git-dpm for
many packages and I leave MRs switched on anyway, even though it does
mean that sometimes I might need to do merges by hand. It's not ideal,
but it's OK. (I understand why people might feel differently, though.)

[Xiyue Deng]

Hi Colin,

Post by Colin Watson

Post by Xiyue Deng
Actually there may be another reason to turn off MR feature: some
packaging workflows don't preserve a linear Git history and hence may
not work well with merging from MR on Salsa. For example, the "git-dpm"
and "git-debrebase" workflows, which use a more complex
merge/fast-forward strategy and merge requests don't integrate well. In
such case it's better to turn off MR to avoid any confusions and let
contributors post patches on BTS, and then the maintainer can apply
those accordingly.

I don't completely agree with the last part of this: I use git-dpm for
many packages and I leave MRs switched on anyway, even though it does
mean that sometimes I might need to do merges by hand. It's not ideal,
but it's OK. (I understand why people might feel differently, though.)

Thanks for sharing your experience. And yes, merging from MR does work
for these workflow to some extents, though it does require understanding
of how they work and handles the merge / fast-forward correctly. This
would require people to be familiar with those workflows to deal with
those, otherwise a directly merged MR would cause the repository layout
becomes dpm/debrebase incompatible.

I brought this up because personally I had done something similar before
on a git-debrebase repository and made the repository a mess. I had to
reach out to more knowledgeable team members to help fix it, and it was
then decided disabling MR could help avoid this happening again. For
those repositories the team and I have added debian/README.source
describing the workflow and people need to consult git-dpm(1),
git-debrebase(1), dgit-maint-debrebase(7), etc. to understand how to
handle those cases properly. Again, this does not mean the developer is
not accepting collaboration, and contributors are welcome to use BTS for
the purpose.

Lastly, I want to clarify I'm in support of keeping MRs open and
promoting a standard workflow for most packages. Meanwhile I would also
like to acknowledge that many other workflows exist because they handle
different use cases well (e.g. carrying Debian-specific patches for a
long time, complex custom packaging checks, etc.). Letting different
workflows exist and work together, though not easy, is also beneficial
for collaboration.

Post by Colin Watson
--

[Philip Hands]

Post by Otto Kekäläinen
Hi!

Post by Sam Hartman
I think it would improve collaboration a lot if we could make an effort
* Merge requests are disabled for that project
* Merge requests are actively watched at least as closely as the BTS

We should revisit the decision to have email notifications disabled by
default in all projects on Salsa. While anyone can enable
notifications for packages they maintain at
https://salsa.debian.org/-/profile/notifications, it would probably be
better if maintainers got notification emails by default from the
Salsa repositories hosting their packages.

This looks to be at the group level (except for repos in my own namespace).

Is there some way to drill down into groups and then set preferences on
an individual repo that's not in one's own namespace?

If so, I'm not seeing it. Perhaps it's possible via the API?

I certainly do not want to set "Watch" level notifications on all repos
in the "debian" group, whereas I would like to set it on packages I
actually maintain (e.g. debian/openqa)

Defaulting to sending notifications for all repos would presumably spam
everyone with anything that happens in any repo in the debian group,
which sounds like a great way of making people hate salsa :-/

Cheers, Phil.

[Otto Kekäläinen]

Post by Philip Hands
Is there some way to drill down into groups and then set preferences on
an individual repo that's not in one's own namespace?

Yes - you can for example open https://salsa.debian.org/debian/openqa
and in the top right corner click on the bell icon, and select
"Watch". That will make you get notifications about Merge Requests in
that one project and not all of /debian/.

[Chris Hofstaedtler]

Post by Sam Hartman

...

Post by Otto Kekäläinen

Post by Otto Kekäläinen
Numerous people are posting Merge Requests on Salsa. Please

help review them!

I think it would improve collaboration a lot if we could make an effort
* Merge requests are disabled for that project
* Merge requests are actively watched at least as closely as the BTS

I agree. Projects that do not want MRs on salsa should have the
feature turned off.

BTW, a lot of other gitlab features should probably be off for most
packaging repositories.

Chris

[Jonas Smedegaard]

Quoting Chris Hofstaedtler (2025-01-24 01:51:27)

Post by Chris Hofstaedtler

Post by Sam Hartman

...

Post by Otto Kekäläinen

Post by Otto Kekäläinen
Numerous people are posting Merge Requests on Salsa. Please

help review them!

I think it would improve collaboration a lot if we could make an effort
* Merge requests are disabled for that project
* Merge requests are actively watched at least as closely as the BTS

I agree. Projects that do not want MRs on salsa should have the
feature turned off.
BTW, a lot of other gitlab features should probably be off for most
packaging repositories.

Currently, when I create a new project at Salsa, I do the following:

1. Among the 3 options for creating a new project, I choose #1:
"Create blank project"
2. Below Settings -> General -> "Visibility[...]", I uncheck all
except "Forks" and "Warn about Potentially Unwanted Characters".

I propose concretely to add a 4th option at that 1st creation page:
"Create only a forkable git repo".

Such 4th option would make my life easier by saving 20-50 clicks for
each created project, and would also more clearly communicate, that the
project has made a deliberate choice of not engaging with other features
offered at the platform.

I am aware that with some time investigating Github API might possibly
be able to reduce the number of webby clicks by using some Gitlab CLI
tool, but I would prefer a generally supported profile of using only git
feature of Gitlab.

Also, I notice that projects I established some time ago with the intent
of only using git repo feature, now has some features enabled which was
missing back when I created the project - i.e. some features at Salsa
seems to be opt-out, not opt-in, which I both find annoying personally
when I want to care about reducing my carbon footprint and communicate
my wishes for ways to collaborate, and also worry can easily be mistaken
in later analysis as "this many Debian developers are happy with these
new feautures, because they have them turned on for their projects",
which is misleading when features are opt-out and enabled silently after
imitial project setup.


- Jonas

[Andrea Pappacoda]

Hi all,

Post by Jonas Smedegaard
Quoting Chris Hofstaedtler (2025-01-24 01:51:27)

Post by Chris Hofstaedtler
BTW, a lot of other gitlab features should probably be off for most
packaging repositories.

"Create blank project"
2. Below Settings -> General -> "Visibility[...]", I uncheck all
except "Forks" and "Warn about Potentially Unwanted Characters".
[...]
some features at Salsa seems to be opt-out, not opt-in, which I both
find annoying personally when I want to care about reducing my carbon
footprint and communicate my wishes for ways to collaborate [...]

Same for me. In addition, on the topic of making things easier for new
contributors, when I first started using Salsa I felt lost in the myriad
of features and options enabled by default. Not only 99% of projects
hosted on Salsa don't need features like "Model experiments", but
keeping them enabled makes the platform harder to use. The BTS, on other
hand, might not have a modern user interface, but its simplicity has
value.

Another big usability improvement in my opinion would be to
automatically enable CI when the `debian/salsa-ci.yml` file is present.
This way, users don't have to be familiar with GitLab's web settings UI
to enable and customize the CI jobs. Not sure if this has been mentioned
before.

Bye!

[Julien Plissonneau Duquène]

Post by Andrea Pappacoda
Same for me. In addition, on the topic of making things easier for new
contributors, when I first started using Salsa I felt lost in the myriad
of features and options enabled by default. Not only 99% of projects
hosted on Salsa don't need features like "Model experiments", but
keeping them enabled makes the platform harder to use. The BTS, on other
hand, might not have a modern user interface, but its simplicity has
value.
Another big usability improvement in my opinion would be to
automatically enable CI when the `debian/salsa-ci.yml` file is present.
This way, users don't have to be familiar with GitLab's web settings UI
to enable and customize the CI jobs. Not sure if this has been
mentioned
before.

Reading things like this I have the feeling that maybe a custom web UI
and service could be a worthy development to complement the stock GitLab
UI. AIUI Salsa admins are not willing to extensively patch the GitLab
codebase for understandable reasons, so an add-on platform may help to
overcome some GitLab limitations and provide additional features
specifically suited to the Debian project. Similar applications are
common in corporate setups.

Among the first features that could be implemented:
- create (or clone) a repository with a choice of suitable configuration
presets (from "nothing but git" to "all bells and whistles")
- check a repo configuration, suggest configuration changes based on
current recommendations (they could be adjusted to team or maintainer
preferences), apply selected changes.

The application could then be extended later for additional features,
such as initializing a repository from team templates and the initial
import of upstream sources, maintenance tasks (Janitor et al) such as
mostly automated routine updates, fix or work around some rights issues
with GitLab, offer an alternate, no-javascript-required, accessible UI
to browse and participate to merge requests and issues (I'm not sure the
stock GitLab UI fares great in terms of accessibility), check a
repository for common issues or deviations (sort of git linter) and
suggest how to fix them, expose additional bulk APIs, expose a
self-service registration UI with improved detection of unwanted peers
and registrant status updates, interact and cross-link issues with the
BTS etc.

Would that make sense?

Cheers,

[Richard Lewis]

Post by Julien Plissonneau Duquène

Post by Andrea Pappacoda
Same for me. In addition, on the topic of making things easier for new
contributors, when I first started using Salsa I felt lost in the myriad
of features and options enabled by default. Not only 99% of projects
hosted on Salsa don't need features like "Model experiments", but
keeping them enabled makes the platform harder to use. The BTS, on other
hand, might not have a modern user interface, but its simplicity has
value.
Another big usability improvement in my opinion would be to
automatically enable CI when the `debian/salsa-ci.yml` file is present.
This way, users don't have to be familiar with GitLab's web settings UI
to enable and customize the CI jobs. Not sure if this has been mentioned
before.

Reading things like this I have the feeling that maybe a custom web UI
and service could be a worthy development to complement the stock
GitLab UI.

I think that sounds like a lot of work in order to duplicate a subset of
the existing functionality -- is another bespoke system what debian
needs?

I do agree that the defaults on salsa should be re-thought -- i'd think
that the few things that debian values, like CI, merge requests and
notifications should be on, and many other things that no-one seems to
use (wikis, badges, service desks etc) should be off - with the option
for anyone to change things.

[Julien Plissonneau Duquène]

Post by Richard Lewis
I think that sounds like a lot of work in order to duplicate a subset of
the existing functionality -- is another bespoke system what debian
needs?

A more affordable option could be to implement some of the features in
the salsa CLI from `devscripts`. Some are already partially done. Would
this get more support? This would not have as much potential for working
around some GitLab limitations though.

Cheers,

[Otto Kekäläinen]

Hi Matthew!

Post by Matthew Vernon

Post by Otto Kekäläinen
Numerous people are posting Merge Requests on Salsa. Please help review them!

I'd much much rather MRs were associated with bug reports; that way I
only have to remember to check one place for outstanding issues in my
packages, and years down the line when I wonder "why did this change get
made" I can look up the bug report in the BTS.

Yes, for bugs that makes sense. Please note however that Merge
Requests is more than just patches/bug fixes. It is a general
mechanism to facilitate code reviews. It does not necessarily make
sense to publish every commit as a patch on bugs.debian.org before
committing it to the git repository. Also, in many cases it may be
most efficient to file at bugs.debian.org only the issue, and do the
actual code submission, testing, and re-submission as a Merge Request.

If you don't like using Salsa or don't like reviewing Merge Requests,
then this call is probably not for you. However, if you want Debian to
grow and you want to welcome new contributors, or in general work in a
collaborative way towards ending single-maintainer packages, reviewing
MRs posted by others a great way to help out.

[Jonas Smedegaard]

Quoting Otto KekÀlÀinen (2025-01-24 01:32:34)

Post by Otto Kekäläinen
If you don't like using Salsa or don't like reviewing Merge Requests,
then this call is probably not for you. However, if you want Debian to
grow and you want to welcome new contributors, or in general work in a
collaborative way towards ending single-maintainer packages, reviewing
MRs posted by others a great way to help out.

That reads very strange to me:

* If I want Debian to grow, then I want Salsa code reviews.
* If I want to welcome new contributors, then I want Salsa code reviews.
* If I want to work collaboratively, then I want Salsa code reviews.

Conclusion: I must drink the Salsa cool-aid, or I am effectively caring
about neither the project, my peers nor about collaboration. Not fully
embracing Salsa makes me a selfish and conservative person.

Please explain to me how I am failing to read correctly what you meant
by that last paragraph I cite above, Otto, because I cannot believe that
you are really arguing the above - I must be mistaken.

Please help me assume good faith.

- Jonas

[Christoph J. Scherr]

Post by Jonas Smedegaard
Quoting Otto KekÀlÀinen (2025-01-24 01:32:34)

Post by Otto Kekäläinen
If you don't like using Salsa or don't like reviewing Merge Requests,
then this call is probably not for you. However, if you want Debian to
grow and you want to welcome new contributors, or in general work in a
collaborative way towards ending single-maintainer packages, reviewing
MRs posted by others a great way to help out.

* If I want Debian to grow, then I want Salsa code reviews.
* If I want to welcome new contributors, then I want Salsa code reviews.
* If I want to work collaboratively, then I want Salsa code reviews.
Conclusion: I must drink the Salsa cool-aid, or I am effectively caring
about neither the project, my peers nor about collaboration. Not fully
embracing Salsa makes me a selfish and conservative person.
Please explain to me how I am failing to read correctly what you meant
by that last paragraph I cite above, Otto, because I cannot believe that
you are really arguing the above - I must be mistaken.
Please help me assume good faith.
 - Jonas

Hello,

As someone just starting out with Debian, I'd like to share my perspective on
this discussion.

I only recently contacted the welcome team and have been following the mailing
lists while waiting for my salsa account approval. From what I've seen so far,
Debian's development process can be quite challenging to understand as a
newcomer.

In my opinion, having a more intuitive web interface through a code forge like
GitLab would lower the barrier to entry for potential contributors. I believe
that normalizing merge requests would particularly benefit contributors from
younger generations, who are more familiar with these modern development
workflows. Exploring the BTS is, for me at least, more confusing for me than
exploring a git repository with issues and merge requests on salsa.

This is my first email to the lists. I hope these thoughts are relevant and
helpful to the discussion.

Best regards,

[Jonas Smedegaard]

Hi Christoph,

Quoting Christoph J. Scherr (2025-01-24 12:13:16)

Post by Christoph J. Scherr

Post by Jonas Smedegaard
Quoting Otto KekÀlÀinen (2025-01-24 01:32:34)

Post by Otto Kekäläinen
If you don't like using Salsa or don't like reviewing Merge Requests,
then this call is probably not for you. However, if you want Debian to
grow and you want to welcome new contributors, or in general work in a
collaborative way towards ending single-maintainer packages, reviewing
MRs posted by others a great way to help out.

* If I want Debian to grow, then I want Salsa code reviews.
* If I want to welcome new contributors, then I want Salsa code reviews.
* If I want to work collaboratively, then I want Salsa code reviews.
Conclusion: I must drink the Salsa cool-aid, or I am effectively caring
about neither the project, my peers nor about collaboration. Not fully
embracing Salsa makes me a selfish and conservative person.
Please explain to me how I am failing to read correctly what you meant
by that last paragraph I cite above, Otto, because I cannot believe that
you are really arguing the above - I must be mistaken.
Please help me assume good faith.
 - Jonas

Hello,
As someone just starting out with Debian, I'd like to share my perspective on
this discussion.
I only recently contacted the welcome team and have been following the mailing
lists while waiting for my salsa account approval. From what I've seen so far,
Debian's development process can be quite challenging to understand as a
newcomer.
In my opinion, having a more intuitive web interface through a code forge like
GitLab would lower the barrier to entry for potential contributors. I believe
that normalizing merge requests would particularly benefit contributors from
younger generations, who are more familiar with these modern development
workflows. Exploring the BTS is, for me at least, more confusing for me than
exploring a git repository with issues and merge requests on salsa.
This is my first email to the lists. I hope these thoughts are relevant and
helpful to the discussion.

Welcome!

You certainly make a relevant point, and I believe that I understand how
that point is central for this discussion.

What troubles me, however, is if that is the only point deemed central
to this discussion.

Yes, it is easier to use tooling that we are used to. Yes, it helps
collaboration around our preferred tooling if user interfaces are as
user friendly as possible. I think we can all agree on that, in
isolation.

I think we can also all agree, that the BTS is not as globally familiar
as Github issue tracking facilities, nor as pleasing and welcoming and
intuitive to use especially for people oriented towards web interfaces.

I don't challenge any of those observations - I agree with them.

What I have a problem with is collaboration optimized *only* towards the
needs of newcomers.

I find the BTS highly valuable *despite* it being unwelcoming, not
because I come from a different time where its design is somehow a bliss
to work with.

I find non-webby git interactions highly valuable *despite* it being
less intuitive than web-based user interfaces and workflows.

We each have a comfort zone, and an understanding of benefits and
qualities of the tooling we are familiar with, and when we engage in
collaboration we may get challenged about that. But finding the ideal
ways to collaborate is a complex assessment, not one that benefits from
reducing the options to a binary "does it raise the bar for newcomers?"
question, in my opinion.

I would love to collaborate with you, but when our ways of working are
different, I would like to look at how our different toolings are
helping each of us (the comfort zones of you and me), our product (the
packages etc. that we are working on concretely) and our project (how
our ways of working may affect others in Debian). It feels to me that
this conversation reduces that conversation to "what is best for
newcomers is best for Debian" and I am not convinced that that is a
sensible reduction.

Hope that makes sense.

- Jonas

[Christoph J. Scherr]

Post by Jonas Smedegaard
Hi Christoph,
Quoting Christoph J. Scherr (2025-01-24 12:13:16)

Post by Christoph J. Scherr
Hello,
As someone just starting out with Debian, I'd like to share my perspective on
this discussion.
I only recently contacted the welcome team and have been following the mailing
lists while waiting for my salsa account approval. From what I've seen so far,
Debian's development process can be quite challenging to understand as a
newcomer.
In my opinion, having a more intuitive web interface through a code forge like
GitLab would lower the barrier to entry for potential contributors. I believe
that normalizing merge requests would particularly benefit contributors from
younger generations, who are more familiar with these modern development
workflows. Exploring the BTS is, for me at least, more confusing for me than
exploring a git repository with issues and merge requests on salsa.
This is my first email to the lists. I hope these thoughts are relevant and
helpful to the discussion.

Welcome!
You certainly make a relevant point, and I believe that I understand how
that point is central for this discussion.
What troubles me, however, is if that is the only point deemed central
to this discussion.
Yes, it is easier to use tooling that we are used to.  Yes, it helps
collaboration around our preferred tooling if user interfaces are as
user friendly as possible.  I think we can all agree on that, in
isolation.
I think we can also all agree, that the BTS is not as globally familiar
as Github issue tracking facilities, nor as pleasing and welcoming and
intuitive to use especially for people oriented towards web interfaces.
I don't challenge any of those observations - I agree with them.
What I have a problem with is collaboration optimized *only* towards the
needs of newcomers.
I find the BTS highly valuable *despite* it being unwelcoming, not
because I come from a different time where its design is somehow a bliss
to work with.
I find non-webby git interactions highly valuable *despite* it being
less intuitive than web-based user interfaces and workflows.
We each have a comfort zone, and an understanding of benefits and
qualities of the tooling we are familiar with, and when we engage in
collaboration we may get challenged about that.  But finding the ideal
ways to collaborate is a complex assessment, not one that benefits from
reducing the options to a binary "does it raise the bar for newcomers?"
question, in my opinion.
I would love to collaborate with you, but when our ways of working are
different, I would like to look at how our different toolings are
helping each of us (the comfort zones of you and me), our product (the
packages etc. that we are working on concretely) and our project (how
our ways of working may affect others in Debian).  It feels to me that
this conversation reduces that conversation to "what is best for
newcomers is best for Debian" and I am not convinced that that is a
sensible reduction.
Hope that makes sense.
 - Jonas

Hello Jonas,

I did not mean that the BTS has no value. Quite the opposite in fact: Without a
method to trace bugs globally, there would be chaos. This is a complex topic, I
just wanted to add my stance on this particular point.

Writing a Pro/Con list might be a good idea, but I am not proficient enough in
both the BTS and GitLab to do so.

Greetings

Christoph

[Jonas Smedegaard]

Quoting Christoph J. Scherr (2025-01-24 15:26:39)

Post by Christoph J. Scherr
Writing a Pro/Con list might be a good idea, but I am not proficient
enough in both the BTS and GitLab to do so.

That sounds like an excellent approach to me.

I will leave that for others, as I have lost my bearing on what is on
topic for this thread¹.

Happy hacking,

- Jonas

¹ https://lists.debian.org/***@cairon.jones.dk

[Christoph J. Scherr]

If we want to continue to use mainly BTS I think you should have an
integration with something that allows you to do more things from the
web interface, in a simple and fast way.
I recently saw this project that seems good to slightly improve some
things, for example: https://fabre.debian.net/
Talking about salsa it comes to mind that it could be used for
authentication if the possibility of doing operations from the web on
BTS (if will be added), therefore keeping the opening of bugs via the
usual tool or via email, renewed navigation in bugs and the possibility
of responses and operations both in the old method via email and from
the web. Among the functions that can be added, perhaps it could be to
connect more easily to any MR in the repository. Add more default links,
to make it easier and faster to reach the packaging repository (if
present), the upstream repository (from upstream metadata, if present)
and possible others. It has been useful to me in many cases (and it will
be useful again), it may seems not be very useful but having some things
more at hand and also being able to reach some parts by making a few
less clicks and changing tabs when perhaps you end up doing such
operations a few hundred or thousand times a year no longer seems like a
useless or insignificant advantage.
What do you think?

Having more options on how to use the BTS would be a good idea in my opinion.
I'd imagine that the BTS stays as the central system, but others connect to it.
For example, merge requests or issues on salsa could optionally (or even always)
be mirrored to the BTS, which might help with the problem that salsa may not run
gitlab some time in the future. That way, a extra platform with easy ui could be
added to the BTS. This would require a sort of API, besides E-Mail, which I do
not know if the BTS has one.

Of course, I'm only playing make believe. And it would all have to be developed
and maintained. Overall, extending the BTS with "extra services" might be a
worthwhile goal.

Best wishes and still hoping my thoughts are relevant,

Christoph

PS: Thanks to Fabio for making me aware, I had accidentally sent this mail only
to him before.

[Jonathan Dowland]

I recently saw this project that seems good to slightly improve some
things, for example: https://fabre.debian.net/

This looks interesting!

The BTS has (or had) a SOAP(!) API. 17 years ago I tried writing a
desktop tool to try and make interacting with it easier. It's now
abandoned, but, I guess I felt that the BTS had some UX issues that
long ago <https://jmtd.net/software/debgtd/>

[Antonio Terceiro]

Quoting Otto Kekäläinen (2025-01-24 01:32:34)

Post by Otto Kekäläinen
If you don't like using Salsa or don't like reviewing Merge Requests,
then this call is probably not for you. However, if you want Debian to
grow and you want to welcome new contributors, or in general work in a
collaborative way towards ending single-maintainer packages, reviewing
MRs posted by others a great way to help out.

* If I want Debian to grow, then I want Salsa code reviews.
* If I want to welcome new contributors, then I want Salsa code reviews.
* If I want to work collaboratively, then I want Salsa code reviews.
Conclusion: I must drink the Salsa cool-aid, or I am effectively caring
about neither the project, my peers nor about collaboration. Not fully
embracing Salsa makes me a selfish and conservative person.
Please explain to me how I am failing to read correctly what you meant
by that last paragraph I cite above, Otto, because I cannot believe that
you are really arguing the above - I must be mistaken.

My reading of what you quoted is: if you want these things to happen,
then reviewing MRs posted by others is *a* great way to help out.

He didn't say it's the *only* way, and didn't imply that not reviewing
MRs on salsa means you don't want Debian to get new contributors etc.

[Jonas Smedegaard]

Quoting Antonio Terceiro (2025-01-24 13:09:10)

Post by Antonio Terceiro

Quoting Otto Kekï¿œlï¿œinen (2025-01-24 01:32:34)

Post by Otto Kekäläinen
If you don't like using Salsa or don't like reviewing Merge Requests,
then this call is probably not for you. However, if you want Debian to
grow and you want to welcome new contributors, or in general work in a
collaborative way towards ending single-maintainer packages, reviewing
MRs posted by others a great way to help out.

* If I want Debian to grow, then I want Salsa code reviews.
* If I want to welcome new contributors, then I want Salsa code reviews.
* If I want to work collaboratively, then I want Salsa code reviews.
Conclusion: I must drink the Salsa cool-aid, or I am effectively caring
about neither the project, my peers nor about collaboration. Not fully
embracing Salsa makes me a selfish and conservative person.
Please explain to me how I am failing to read correctly what you meant
by that last paragraph I cite above, Otto, because I cannot believe that
you are really arguing the above - I must be mistaken.

My reading of what you quoted is: if you want these things to happen,
then reviewing MRs posted by others is *a* great way to help out.
He didn't say it's the *only* way, and didn't imply that not reviewing
MRs on salsa means you don't want Debian to get new contributors etc.

Ah, I see it now. Thanks, Antonio.


Quoting Otto Kekï¿œlï¿œinen (2025-01-24 01:32:34)

Post by Antonio Terceiro
If you don't like using Salsa or don't like reviewing Merge Requests,
then this call is probably not for you.

Oh, I am sorry if my posts in this thread have been generally off-topic:
I thought it was about Debian in general, not more narrowly a discussion
between those already convinced that a Salsa-centric workflow is great.


- Jonas

[Otto Kekäläinen]

Hi Jonas!

Post by Jonas Smedegaard

Post by Otto Kekäläinen
If you don't like using Salsa or don't like reviewing Merge Requests,
then this call is probably not for you. However, if you want Debian to
grow and you want to welcome new contributors, or in general work in a
collaborative way towards ending single-maintainer packages, reviewing
MRs posted by others a great way to help out.

* If I want Debian to grow, then I want Salsa code reviews.
* If I want to welcome new contributors, then I want Salsa code reviews.
* If I want to work collaboratively, then I want Salsa code reviews.
Conclusion: I must drink the Salsa cool-aid, or I am effectively caring
about neither the project, my peers nor about collaboration. Not fully
embracing Salsa makes me a selfish and conservative person.
Please explain to me how I am failing to read correctly what you meant
by that last paragraph I cite above, Otto, because I cannot believe that
you are really arguing the above - I must be mistaken.
Please help me assume good faith.

First of all, thanks for maintaining 1000+ packages in Debian, which
is very impressive, and you clearly have a good workflow for yourself.
I am not asking you to change it. Please continue to maintain those
1000+ packages :)

My original message
https://lists.debian.org/debian-devel/2025/01/msg00267.html and the
subject of this thread was to encourage people on this mailing list to
a) note that there are a lot of open MRs from people who want to
contribute to Debian (and also from existing DDs who want to have a
second pair of eyeballs), b) and that those who like using Salsa are
encouraged to spend some time on reviews (and not just on packaging
their own packages).

I specifically wrote that chapter you quoted with the intent that
people who don't like using Salsa should ignore the message, or that
people who are ok using Salsa but haven't done code reviews should try
it out. I am sorry if it came off wrong. Maybe next time I should
start the message with something like "if you don't use Salsa, stop
reading", but that too could be viewed negatively from some angles.

I wish we could all realize that anybody who cares enough about Debian
so invest time in these mailing list discussions are likely wishing
Debian a good future, and avoid negative interpretations. Thanks for
sharing your read and asking for clarification. Hopefully this reply
clarifies that there was no explicit or hidden blame.

Again, thanks for contributing to Debian with over a thousand packages!

[Jonas Smedegaard]

Hi Otto,

Quoting Otto KekÀlÀinen (2025-01-24 18:24:55)

Post by Otto Kekäläinen
Hi Jonas!

Post by Jonas Smedegaard

Post by Otto Kekäläinen
If you don't like using Salsa or don't like reviewing Merge Requests,
then this call is probably not for you. However, if you want Debian to
grow and you want to welcome new contributors, or in general work in a
collaborative way towards ending single-maintainer packages, reviewing
MRs posted by others a great way to help out.

* If I want Debian to grow, then I want Salsa code reviews.
* If I want to welcome new contributors, then I want Salsa code reviews.
* If I want to work collaboratively, then I want Salsa code reviews.
Conclusion: I must drink the Salsa cool-aid, or I am effectively caring
about neither the project, my peers nor about collaboration. Not fully
embracing Salsa makes me a selfish and conservative person.
Please explain to me how I am failing to read correctly what you meant
by that last paragraph I cite above, Otto, because I cannot believe that
you are really arguing the above - I must be mistaken.
Please help me assume good faith.

First of all, thanks for maintaining 1000+ packages in Debian, which
is very impressive, and you clearly have a good workflow for yourself.
I am not asking you to change it. Please continue to maintain those
1000+ packages :)
My original message
https://lists.debian.org/debian-devel/2025/01/msg00267.html and the
subject of this thread was to encourage people on this mailing list to
a) note that there are a lot of open MRs from people who want to
contribute to Debian (and also from existing DDs who want to have a
second pair of eyeballs), b) and that those who like using Salsa are
encouraged to spend some time on reviews (and not just on packaging
their own packages).
I specifically wrote that chapter you quoted with the intent that
people who don't like using Salsa should ignore the message, or that
people who are ok using Salsa but haven't done code reviews should try
it out. I am sorry if it came off wrong. Maybe next time I should
start the message with something like "if you don't use Salsa, stop
reading", but that too could be viewed negatively from some angles.
I wish we could all realize that anybody who cares enough about Debian
so invest time in these mailing list discussions are likely wishing
Debian a good future, and avoid negative interpretations. Thanks for
sharing your read and asking for clarification. Hopefully this reply
clarifies that there was no explicit or hidden blame.
Again, thanks for contributing to Debian with over a thousand packages!

Thanks for clarifying, and sorry for (yet again) reading too much into
what you are writing - as Antonio also pointed out to me.

Also thank you for the kind words about my packaging efforts - for the
record it is however an exaggeration by about 20%.

NB! For anyone reading this: I would be delighted to collaborate more on
the packages that I am involved in maintaining, so if you happen to have
a favorite among "my" packages and want to help maintain it, then please
do get in touch. Also, if you find a favorite but for some reason is
not in the mood for collaborating with me in particular, then please
reach out as well - I might be willing to let go of it. :-)


- Jonas

[Jonathan Dowland]

Post by Matthew Vernon
I'd much much rather MRs were associated with bug reports; that way I
only have to remember to check one place for outstanding issues in my
packages, and years down the line when I wonder "why did this change get
made" I can look up the bug report in the BTS.
Yes, for bugs that makes sense. Please note however that Merge
Requests is more than just patches/bug fixes. It is a general
mechanism to facilitate code reviews. It does not necessarily make
sense to publish every commit as a patch on bugs.debian.org before
committing it to the git repository. Also, in many cases it may be
most efficient to file at bugs.debian.org only the issue, and do the
actual code submission, testing, and re-submission as a Merge Request.

I don't think what you write here is incompatible with what Matthew
suggested (unless I've misunderstood either or both of you).

The BTS is the project's System of Record for bug tracking. Many devs
are quite comfortable with relying upon email alerts from the BTS.
Rather than require them to adopt alerts from Salsa, if MRs from Salsa
were automatically bridged to BTS bugs, either existing ones (where
identified) or new ones, greybeards can continue with their established
workflows, our system-of-record is kept up-to-date *and* the Salsa UI is
available for new or prospective contributors.

I think you are arguing that all package changes, not just bug fixes,
should be reviewed and thus go through the MR process, but would not
warrant a BTS bug. I think, with functioning integration/automation,
having potentially-superfluous BTS issues would not be a problem.

What I propose is very hand-wavey, I think it's worth exploring and
sketching out in more detail.

(We appear to be carefully avoiding a discussion about the problems that
the BTS has at the moment, but we can't avoid that forever.)