Re: On using Merge Requests on Salsa (Re: debian/watch version 5)
On Fri, Aug 22, 2025 at 01:15:54PM -0700, Otto Kekäläinen wrote:
> Maybe we can have more of this, but note that we already have at least
> 7 avenues for the information about an open MR can reach the
> maintainer: https://wiki2025.debian.org/wiki/Salsa. I think this
> ultimately boils down to people who dislike Salsa vs others. Seeing
> that you host none of your packages on Salsa I am not surprised you
> are not keen on the topic of looking at MRs, and I respect that, but
> for the rest of the crowd, I still want to remind checking for
> potential open MRs.
Actually, I do have a repo on Salsa:
https://salsa.debian.org/tytso/e2fsprogs
It's rather deliberlately not under the debian hierarchy because I do
*not* believe in letting random people submit changes to the repo, and
unlike those who were apparently taken by surprise, I had taken a very
careful look and then said, yeah.... oh, HELL, no.
My personal bias comes from my taking over e2fsprogs package
maintenance from the previous Debian maintainer for e2fsprogs who
attempted to enable > 2TB files for Debian via an out-of-tree patch
--- but who botched the (apparently simple, but not so much) patch
leading to people who complaining to me as the upstream project
maintainer about data loss caused by a laudable goal to close out a
feature request bug. So I'm a little bit less.... trusting.... about
people making changes to critical system software without close
supervision.
> Just to clarify, you don't think it is good to have a culture in
> Debian that maintainers tend to check for open Merge Requests? The
> rest of the paragraph was about something else.
It's the culture where people receive nag e-mails which is what I
object to.
> Other distros have been able to agree on workflow changes and more
> unified workflows than Debian. An even Debian does have examples of
> its own, like moving to Debhelper 15 years ago.
Debhelper is still optional, and I don't ever recall people sending
public messages "encouraging" other DD's to move to debhelper.
I think that's perhaps the key. Saying "think of the newcomers",
with the unstated implication that if they don't cave into your nag
e-mails, they must not care about newcomers, is perhaps not helpful.
(Note that I have *not* said that people who let people randomly
checkin changes to a git repo must not care about software quaity.
That's just my bias; perhaps informed by some painful history, but
still my personal bias.)
Instead, the way most packages migrated to debhelper was because it
saved the package maintainers *time*. Converting over to debhelper
did take a non-trivial amount of time, but I did it because it fixed
some problems that were annoying me as the package owner, and because
in the long run, I saw that it saved me time. I didn't switch because
of e-mails sent to debian-devel *encouraging* me to switch to
debhelper as the only good and right way to do things.
Similarly, I started using dgit because it saved me time and was more
convenient. It has some other benefits to the project which is
motivated people who have spent a lot of time creating and improving
dgit, but it's not why I switched.
So for example, if you want to get more people to use the MR workflow,
you might want to figure out why it might be causing them more
friction, and to try to make changes to Salsa to make that friction go
away, given someone's current favored workflow. Don't ask them to
take on more work because "think of the children^H^H^H^H^H^H^H^H
newcomers". Instead, make it *better* for them, gievn their workflow,
so that they *want* to change for their own reasons.
> I don't think being a
> volunteer organization necessarily puts us in an inferior situation.
> It's just that the decision making process is different, and we need
> to arrive on them by multi-year mailing list discussions and parallel
> work on tooling and documentation that makes the workflows better and
> compatible with all use cases.
Sure. I would add to that, and "remember that different people do
volunteer work for different reasons, and their priorities might be
different from your priorities."
Cheers,
- Ted
Reply to: