maintainers: drop gm6k

[wolfgangwalther]

gm6k is not actively maintaining his packages. While there is some current activity on GitHub and in the Nixpkgs repo, none of that is related to maintaining the packages he's listed for.

The contribution guidelines say:

We would typically look at it if we notice that the author hasn't reacted to package-related notifications for more than 3 months.

Since Isidor can't be requested for review by CI without GitHub handle, we'd have to look at a different metric.

There has been no activity on the 5 update PRs to minetest-mapserver. luci-go is 10 months outdated, with a lot of activity upstream and failing to build since March this year.

I'd argue, you are not actively maintaining, @zeuner. Thus, I propose to drop your maintainer handle according to the contribution guidelines.

If you'd like to stay a maintainer, please respond within a week, according to the guidelines. It would also be great to let us know how you intend to actively maintain your packages despite the inability to be requested for review from CI.

Things done

• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

---

Add a 👍 reaction to pull requests you find important.

[philiptaron]

Let's wait for a response for a week.

See also:

• #273220
• #275328
• #275396
• #275605
• #273146

[zeuner]

Thank you for your kind expression of interest.

Indeed, you're right that I have become less active on nixpkgs lately. I am still highly enthusiastic about the nixpkgs technology. However, I think there are some rather bold community issues that lead to demotivation. In late 2023, a member created a destructive PR against some files I'm responsible for, blocked me from responding to the PR, merged it, and tracked down my PRs in order to suggest that they should not be merged. Since then, I tried to mitigate such issues a bit (#356607), but so far we have no effective mechanism that would prevent this in case of someone getting into a destructive mood again in the future. Despite this highly demotivating incident, I am very interested in contributing more again, considering that I also found members who have a more constructive idea of interacting, and who value my contributions. As I'd like to continue my work on the more build-intensive packages, I acquired new hardware to help on this. On the other hand, I still think there is more to be done to mitigate destructive interaction patterns.

When it comes to the packages I maintain, I take the raised issues very seriously. Still, I'm a bit surprised by what is presented:

I have been aware of the minetest-mapserver PRs, and I looked into them from time to time. They didn't suggest any interaction need, though. They just change the version number and hashes, so they don't interfere with how I had the package in mind or how I feel comfortable with supporting it. Did you expect me to ACK them all?

Regarding luci-go, it's a dependency for more chromium-related packages I planned to contribute, but I worked on that effort on an older checkout. I wasn't aware of other packages already using it, so I didn't bother to update it. What surprises me is that no one (not even you, @wolfgangwalther) filed an issue against the package before presuming it's unmaintained. I would understand the criticism if I ignored an issue. Still, I'll have a look now since you seem to need a newer version.

Once, I worked on a PR for several weeks, together with other members, and the registered maintainer didn't provide any reaction at all, nor on subsequent PRs. Still, no one suggested he should be removed. Maybe he would have reacted if we changed the package in ways he didn't intend. Considering that there is no actual practical impact visible from my presumed "non-maintenance", one might think that it implies external reasons (#437085) for requesting a drop. I guess this is not the implication you intended.

I request to close this PR.

[pbsds]

I have no hope to be able to match your verbosity in kind, so i'll be brief:

• We can't really do anything about people choosing to block you out of fear
• We do encourage maintainers to maintain their packages, which include testing version bump PRs to see if they're safe to merge or not. Approving PRs really does help us out.
• luci-go not building for 10 5 months means it is effectively unmaintained.

You have yet to answer the central question by @wolfgangwalther:

If you'd like to stay a maintainer, please respond within a week, according to the guidelines. It would also be great to let us know how you intend to actively maintain your packages despite the inability to be requested for review from CI.

(emphasis mine)

[eclairevoyant]

• luci-go not building for 10 5 months

Obviously I'm not the maintainer, but...where's the reported issue for it? Or generally how would a maintainer know? I've not yet found a working mechanism to get automatically pinged about broken packages (subscribing to hydra notifications did nothing last time I checked).

[zeuner]

For the record, a buildable PR for luci-go is in place (#437389). In the future, should you find problems with a package, I suggest filing an issue through the proper channel. After pinging a maintainer and failing to receive a response, the documented process (https://github.com/NixOS/nixpkgs/tree/master/maintainers#how-to-lose-maintainer-status) is to file a PR to remove the maintainer from the given package. I don't think a bulk approach is even intended.

[wolfgangwalther]

[minetest-mapserver] Did you expect me to ACK them all?

Yes.

Still, I'll have a look now since you seem to need a newer version.

I don't. The fact that this is broken for months without anybody noticing probably means this package is unused. So a viable option might also be to drop the package. Especially since you're saying it's actually only useful as a dependency? In that case, if there's no in-tree user, there's no justification to keep it, I think.

Considering that there is no actual practical impact visible from my presumed "non-maintenance",

There is practical impact:

• PRs without a pinged maintainer get a needs: reviewer label and need manual interaction to find somebody to review.
• PRs without feedback from maintainers need to be reviewed by others, who are not as familiar with the package. That's additional work, compared to the maintainers.
• PRs without feedback from maintainers need to be explicitly waited for until the "waiting for maintainer feedback period" expires. See https://github.com/NixOS/nixpkgs/tree/master/maintainers#definition-and-role-of-the-maintainer. Not everyone does that, but I certainly do - and its additional work for me and an additional delay for package updates. Keeping many otherwise ready PRs open for longer than needed also hurts overall visibility of these PRs that still need to be worked on.

one might think that it implies external reasons (#437085) for requesting a drop. I guess this is not the implication you intended.

No, that's not the case. I regularly open these kinds of PRs, see https://github.com/NixOS/nixpkgs/issues?q=state%3Aclosed%20is%3Apr%20author%3Awolfgangwalther%20maintainers%20drop%20in%3Atitle. I do so whenever I encounter an inactive maintainer. In this case, I came here via running the script in #437078.

Obviously I'm not the maintainer, but...where's the reported issue for it? Or generally how would a maintainer know?

I think the general assumption today is that a maintainer has a higher likelihood of using their own packages and thus would eventually notice the package breaking.

I've not yet found a working mechanism to get automatically pinged about broken packages (subscribing to hydra notifications did nothing last time I checked).

Yeah, that's true. That's certainly something that we all need, I don't know a good way either.

[wolfgangwalther]

After pinging a maintainer and failing to receive a response, the documented process (https://github.com/NixOS/nixpkgs/tree/master/maintainers#how-to-lose-maintainer-status) is to file a PR to remove the maintainer from the given package. I don't think a bulk approach is even intended.

Interesting, I see what you mean. The text is indeed written specifically for a package. We are living it differently for quite a while already, so this just means that the contribution guidelines need better wording.

[pbsds]

I've not yet found a working mechanism to get automatically pinged about broken packages (subscribing to hydra notifications did nothing last time I checked).

Hydra does indeed have email notifications disabled, which really is unfortunate. I frequently check https://zh.fail/failed/overview.html, a third party tool which also does not seem to work for his maintainer entry.

---

What I have truly yet to understand is why you (@zeuner) goes to such a length to not add your github id to maintainer-list.nix. What do you gain from not doing so?

[SigmaSquadron]

I think this can be closed, as @zeuner has expressed interest in continuing to be a maintainer for Nixpkgs.

w.r.t. #437085, could @zeuner please add their GitHub information to their maintainer entry in a separate PR?

[wolfgangwalther]

I think this can be closed, as @zeuner has expressed interest in continuing to be a maintainer for Nixpkgs.

I disagree, I expect an answer to my actual question, also see #437082 (comment).

My conclusion with the current information is quite different: There is currently nothing to be gained from a dys-functional maintainer entry, so @zeuner could just as well be an "unlisted maintainer". Not being listed in the file does not stop someone from contributing.

w.r.t. #437085, could @zeuner please add their GitHub information to their maintainer entry in a separate PR?

Once that happens, this PR would be redundant, yes. But given the history, this is unlikely to happen.

[wolfgangwalther]

With #437469 merged, github and githubId are now a requirement for the maintainer entry.

@zeuner how would you like to proceed? To comply with these requirements, you have the choice of:

• Approving this PR to be merged.
• Opening a PR yourself to add the respective github/githubId data for your maintainer handle.

Of course, you also have the option to not accept this requirement. In this case, you'd have to escalate this issue further, for example via the SC. In this case, I would still merge this PR, even if only temporary - it can always be reverted should there be a need to.

As initially mentioned already, should there be no feedback on this within a week, I'd also merge.

[zeuner]

What I have truly yet to understand is why you (@zeuner) goes to such a length to not add your github id to maintainer-list.nix. What do you gain from not doing so?

Adding GitHub data to maintainer-list.nix is likely to result in people considering the GitHub account to be a reliable contact method. This is not the case. I experienced both cases where notifications were not reliably sent by e-mail, and where login was not reliably possible. Furthermore, GitHub also allows users to deliberately prevent communication, making it an even less reliable communication method. There are even members who want to keep the the communication over GitHub as unreliable as it already is (#356607). So, honouring my responsibilities as a maintainer, the most obvious solution is to provide only communication methods over which I have enough control. This way, users can be sure that they can reach me in case of issues with packages I maintain.

[zeuner]

If you'd like to stay a maintainer, please respond within a week, according to the guidelines.

I already said so. Apparently, for other maintainers, this is sufficient (#422990), so I request to close this PR again.

It would also be great to let us know how you intend to actively maintain your packages despite the inability to be requested for review from CI.

As far as I can see, the stated "inability" is largely caused by community members who repeatedly block PRs (NixOS/ofborg#665, #437407) that would improve the current vendor-locked-in situation regarding pinging. So, the more accurate wording would be "despite a part of the community refusing to request reviews from you".

This community issue would be worth resolving. Anyhow, until this happens, I can also poll the issue/PR tracker to find relevant threads.

[minetest-mapserver] Did you expect me to ACK them all?

Yes.

Ok, I will keep this in mind. Anyhow, in this case, I checked my communication for pings both on luci-go and minetest-mapserver you mentioned. The first occurrence of something that could be considered a maintainer ping is your message from August 26th. I responded within less than a week, noticing that minetest-mapserver looks fine and providing a fix for luci-go. So, my maintainer obligations according to the documentation are obviously met.

Still, I'll have a look now since you seem to need a newer version.

I don't. The fact that this is broken for months without anybody noticing probably means this package is unused. So a viable option might also be to drop the package. Especially since you're saying it's actually only useful as a dependency? In that case, if there's no in-tree user, there's no justification to keep it, I think.

It contains at least cipd, a binary which is currently used by other packages which download it as a binary blob. Maybe there are other cases I'm not aware of. So, I'd argue it's useful to improve the source provenance situation to the benefit of security-constrained environments.

I do so whenever I encounter an inactive maintainer. In this case, I came here via running the script in #437078.

The script doesn't seem to contain any logic that could be possibly useful to determine maintainer inactivity. It's likely that the approach leads to a biased outcome.

Obviously I'm not the maintainer, but...where's the reported issue for it? Or generally how would a maintainer know?

I think the general assumption today is that a maintainer has a higher likelihood of using their own packages and thus would eventually notice the package breaking.

I did. I just didn't use it on the current git master before you pinged me. That's what communication is for.

After pinging a maintainer and failing to receive a response, the documented process (https://github.com/NixOS/nixpkgs/tree/master/maintainers#how-to-lose-maintainer-status) is to file a PR to remove the maintainer from the given package. I don't think a bulk approach is even intended.

Interesting, I see what you mean. The text is indeed written specifically for a package. We are living it differently for quite a while already, so this just means that the contribution guidelines need better wording.

The mere fact that the maintainer documentation hasn't been followed by some does not suffice to assume it should be changed. I'm not even sure the "ad hominem" approach you seem to suggest would have any advantages. The goal should be to have, for each package, an accurate view of whether it's maintained and who can be contacted in case of changes/breakage/anything, shouldn't it?

[zeuner]

With #437469 merged, github and githubId are now a requirement for the maintainer entry.

This is off-topic here. This PR was opened under the premise of failing maintainer obligations. This has already been disproved, so this PR should be closed.

If you want to proceed with your mission, this should go into a separate PR, which clearly states the reasons for the intended drop.

Merging this PR would be defamatory at best, as it would create the wrongful impression that I had failed maintainer obligations, even though I quickly responded to the first ping I received about the packages you mentioned.

[zeuner]

* Opening a PR yourself to add the respective github/githubId data for your maintainer handle.

Assuming that I wanted to add GitHub data to the entry (but see above), in the current situation it would probably not lead to the effect you intend. At least in the EU, consent-based processing of personal data requires the consent to be freely given (see https://gdpr-info.eu/issues/consent/). Your message could be interpreted as a means pressure, considering that it threatens with dropping the maintainer entry. So the consent would probably be considered invalid.

If you want to talk about adding GitHub handles to maintainer entries, it would be advisable to first remove any signs of pressure.

[zeuner]

In this case, you'd have to escalate this issue further, for example via the SC.

As suggested by the author, I'd like to kindly ask for your help, @NixOS/steering. The author opened this PR based on the accusation of me failing on my maintainer obligations. This could easily be disproved, the relevant notification of me as a maintainer occurred on August 26th, after which I didn't nearly take 3 months to react, but less than a day. For other maintainers, this was considered sufficient (see #422990). In my case, the author instead started to change the documentation through other PRs in order to create new reasons to drop the maintainer entry.

To prevent damage, I'm kindly asking to close this PR until the issues with it have been resolved.

Furthermore, I would hope for your intervention so maintainers will be more valued and receive more reliability from the community. I believe it's in the best interest of our community if talented developers can enjoy their role as a maintainer, rather than living in constant fear of destructive actions from other community members.

[emilazy]

This is the second time you’ve used incredibly dubious veiled legal threats to try and derail a requirement that affects no active maintainer other than you and that there has been strong consensus for across multiple PRs? At this point I think this is more a matter for @NixOS/moderation, frankly…

There’s no reasonable argument for the link between your maintainer entry and GitHub account being private, considering your extensive participation in public discussion about that link across multiple years. Your argument that the GDPR entitles you to unilaterally hold up both being invited to amend your maintainer entry to meet a new requirement, and dropping your maintainer entry as it does not meet that requirement, is absurd and disruptive.

[SigmaSquadron]

Good day, @zeuner.

If you want to proceed with your mission, this should go into a separate PR, which clearly states the reasons for the intended drop.

Merging this PR would be defamatory at best, as it would create the wrongful impression that I had failed maintainer obligations, even though I quickly responded to the first ping I received about the packages you mentioned.

#439407 has been opened per your request. As you do not wish to add your GitHub contact information to the maintainer list, a recently implemented requirement in #437469, we would like to respect your right to privacy by removing your maintainer data from Nixpkgs entirely. The removal in #439407 clearly states that your request for privacy with regards to this new data collection requirement could not be reconciled with your continued maintenance in Nixpkgs.

Your acknowledgement of #439407 is not required, as you have already made your wishes clear here.

Thank you for your attention to this matter.

[SigmaSquadron]

Superseded by #439407.

[qzylinra]

zeuner, it seems that non-members cannot mention the organization team. You may need to contact them through other channels. You can open a new PR to remove your maintainer entry to avoid incorrect information here. Losing maintainer status is not a big deal (the previous maintainer role had little impact since the GitHub information was not filled out). You can still continue contributing.

[zeuner]

This is the second time you’ve used incredibly dubious veiled legal threats to try and derail a requirement that affects no active maintainer other than you and that there has been strong consensus for across multiple PRs? At this point I think this is more a matter for @NixOS/moderation, frankly…

It seems weird that you defamate, and at the same time call for moderation. But yes, if you continue spreading wrongful accusations, then this would be a case for moderation.

There’s no reasonable argument for the link between your maintainer entry and GitHub account being private, considering your extensive participation in public discussion about that link across multiple years. Your argument that the GDPR entitles you to unilaterally hold up both being invited to amend your maintainer entry to meet a new requirement, and dropping your maintainer entry as it does not meet that requirement, is absurd and disruptive.

I have seen that quite some committers enjoy to ignore it, but the EU-GDPR, among other objectives, mandates availability of personal data that is required for processing. This directly contradicts the approach of just deleting personal data of maintainers you happen to disagree with. If you think conforming to the EU-GDPR in a project which touches the EU market is "absurd", this is something we cannot properly resolve here.

[zeuner]

zeuner, it seems that non-members cannot mention the organization team. You may need to contact them through other channels.

Not sure where else a membership is necessary. Anyway, I can try to invoke other channels.

Losing maintainer status is not a big deal (the previous maintainer role had little impact since the GitHub information was not filled out). You can still continue contributing.

Without a maintainer entries, package contributions are regularly refused by committers. Many serious contributions cannot be implemented properly without being able to put at least some of its components in separate packages. Therefore, contributing makes little sense when sufficiently powerful community members delete the maintainer entry.

[dcarosone]

@zeuner, as a matter of @NixOS/moderation, it is time for this to stop. There may be issues with the process and barriers to contribution in many forms, but your arguments will not be taken in good faith when made using veiled legal threats in a closed issue. You are correct that it cannot be properly resolved here.

[qzylinra]

Yes, in this case it’s generally not possible to add new packages. But other contributions are still valuable, there are many committers who can review and merge your PR.