Hi Joost,
Am Thu, May 08, 2025 at 05:49:41AM +0200 schrieb Joost van Baal-Ilić:
> I'm with Jonas and h01ger here: I don't think the benefits of the current
> ITM-prodedure are bigger than the bad side effects. And even more people
> voiced this opinion, e.g. @ https://wiki.debian.org/DebianMentorsFaq it says:
>
> Please Note: Don't go e-mailing maintainers with e-mails like "Your package
> looks unmaintained, I'm going to hijack your package". It helps nobody, and
> ensures that you will have at least one very unhappy Debian developer. "
>
> (thanks to urbec for finding this quote.)
That's a good catch--thank you. But I'd gently point out that the quote
says this *ensures* at least one very unhappy Debian developer, which is
logically disproven by any instance where such contact is welcome.
Personally, I'd be delighted if someone found a package where I'm listed
as Uploader, improved it, mailed me, and uploaded it. I see that as
collaboration, not hijack.
Of course, it's fair to say *some* developers may feel unhappy when
approached this way. That's an appropriate caution for newcomers, and
the Wiki rightly reflects that. But turning this into a general argument
against any form of early communication or coordination effort seems too
broad.
Ultimately, we often face a tradeoff:
1. A volunteer possibly feeling intruded upon, versus
2. Users left with broken packages or unanswered bugs.
Our Social Contract commits us to prioritize users and free software. We
need to find ways to balance both goals effectively, as scaring away
volunteers (item 1) undermines our ability to fulfill goal 2. My goal is
to navigate that space respectfully--if there's a better way to write
such emails, I'm all ears.
At the same time, we also need to acknowledge a recurring issue:
volunteers rarely announce when they become unavailable or unable to
continue work they once actively maintained. We must find ways to
address this gap constructively. I'd welcome suggestions on how to
approach this more effectively.
> There's also a _reason_ we do not enforce the use of salsa for our packaging
> work yet.
ACK. However, if you look at the commit logs of the repositories I've
created, there are lots of contributions not just from me. The real goal
is to get the community involved in maintaining packages, and for that,
Salsa plays a crucial role. The Package Salvage team was formed to
demonstrate how to address bugs, and using Salsa in these cases is key.
This isn't about enforcing Salsa as the only platform for package
maintenance, but rather gently migrating those packages that aren't
there for the _reason_ you are refering to.
> Maybe the best course of action now would be to try to get a GR on
> such a policy change. (Ideally after the upcoming release, of course.)
I don't believe the DPL should initiate GRs. I also think that when this
GR does happen (and I'm confident it will), someone else will be DPL.
I'd love to help smoothen the path for this GR, and I know how I'll vote.
However, I'll focus on tasks I can manage within this term.
> Looking forward to join the session on this @ DebConf25 Brest!
Same heres--—and thanks a lot for sharing your thoughts
Andreas.
--
https://fam-tille.de
