Hi! I think Soren and Antonio summarized what I am thinking as well. If there are seemingly unmaintained packages and we have people who are willing to take care of them and update/refresh them by doing something between a small NMU and a full-scale adoption, then that is only positive.
On Wed, 7 May 2025 at 21:06, Joost van Baal-Ilić <joostvb-deb...@mdcc.cx> wrote: > > Hi Andreas e.a., > > [Please Cc me on replies, I'm not subscribed.] > > 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. " Why do people who object this have to resort to words like "pressure", "coercion" or "hijacking"? Seems to me you are intentionally trying to make it sound negative by labelling, instead of discussing the main problem of half-abandoned packages and how to enable collaboration on them. All the examples Andreas listed are seemingly unmaintained packages. This is not about your packages. If some day somebody asks about your package, and you don't want it to be touched and prefer to keep your package in the current state, you can just reply in email using one of the suggested response examples Soren outlined. > There's also a _reason_ we do not enforce the use of salsa for our packaging > work yet. 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.) This is not about enforcing version control or Salsa. This is about how to handle packages that are not officially orphaned and which are not officially being salvaged, but something in between. If the new person (or team) putting energy in a package decides that their time is more efficiently spent when version control is utilized, it is just a side effect of it, and it happens after the original maintainer has had a chance to object to other people touching the package.
