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
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.
938 (9657) https://salsa.debian.org/groups/debian/-/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.
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.
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
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 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.
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.
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.
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!
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.
Frustrated,
Chris
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.
619 (1242) https://salsa.debian.org/groups/java-team/-/merge_requests
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?
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
On 14/01/25 23:14, Otto Keklinen wrote:
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]),
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
[1] https://bugs.debian.org/1051861
[2] https://bugs.debian.org/1057101
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.
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.
Otto Kekäläinen <otto@debian.org> writes:
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.
Otto Kekäläinen <otto@debian.org> writes:
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.
On 23/01/25 15:28, Matthew Vernon wrote:[...]
Otto Kekäläinen <otto@debian.org> writes:
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.
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?
Or forget about the BTS and accept Salsa as the main place where
improvements are discussed?
Quoting Gioele Barabucci (2025-01-23 15:56:24)
On 23/01/25 15:28, Matthew Vernon wrote:[...]
Otto Keklinen <otto@debian.org> writes:
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.
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" == Jonas Smedegaard <jonas@jones.dk> writes:
Are discussions at Salsa preserved years down the line?
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
On Thu, Jan 23, 2025 at 03:56:24PM +0100, Gioele Barabucci wrote:
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.
...>> > 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
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
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,
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" == Otto Kekäläinen <otto@debian.org> writes:
Hi,
On Thu, 23 Jan 2025 at 17:52, Wookey <wookey@wookware.org> wrote:
..
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 :)
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.
Also note that the contents that really matter is the git repositories
themselves.
I do not agree with this premise.
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).
On 24/01/25 09:00, Julien Plissonneau Duquène wrote:
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).
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.
Hi!
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
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.
* Sam Hartman <hartmans@debian.org> [250123 23:47]:
...>> > 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
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
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.
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.
Quoting Otto Kekäläinen (2025-01-24 01:32:34)
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
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.
Quoting Otto Keklinen (2025-01-24 01:32:34)
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.
Quoting Chris Hofstaedtler (2025-01-24 01:51:27)
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".
[...]
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 [...]
On Fri, 2025-01-24 at 11:07 +0100, Jonas Smedegaard wrote:
Quoting Otto Kekäläinen (2025-01-24 01:32:34)
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
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.
"Otto" == Otto Kekäläinen <otto@debian.org> writes:
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.
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.
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.
On Fri, Jan 24, 2025 at 11:07:40AM +0100, Jonas Smedegaard wrote:
Quoting Otto Kek�l�inen (2025-01-24 01:32:34)
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.
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.
If you don't like using Salsa or don't like reviewing Merge Requests,
then this call is probably not for you.
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.
Le 2025-01-24 09:49, Gioele Barabucci a écrit :[...]
[...]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.
Hi Christoph,
Quoting Christoph J. Scherr (2025-01-24 12:13:16)
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
"Gioele" == Gioele Barabucci <gioele@debian.org> writes:
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.
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?
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.
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.
Hi Jonas!
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.
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!
Quoting Gioele Barabucci (2025-01-24 09:49:27)create
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*
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?
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?
Jonas Smedegaard <jonas@jones.dk> writes:
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?
I recently saw this project that seems good to slightly improve some
things, for example: https://fabre.debian.net/
Le 2025-01-24 13:00, Andrea Pappacoda a écrit :
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.
On 1/23/25 8:46 PM, Simon Josefsson wrote:
Jonas Smedegaard <jonas@jones.dk> writes:
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.
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)
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 assume the Salsa admins do have a way to permanently redact a
discussion thread that contains something illegal or abusive, if it
becomes necessary.)
Wayback Machine
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
Am Sun, Jan 26, 2025 at 01:06:00AM +0100 schrieb 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
requests: 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.
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?
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (1 / 15) |
| Uptime: | 160:12:47 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,056 |
| Messages: | 6,416,492 |