treewide: decomissionate urandom

[AndersonTorres]

Since urandom is inactive.

Description of changes

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[emilylange]

🤡

[teutat3s]

Funny, "inactive":

nixpkgs/maintainers/maintainer-list.nix

Lines 21464 to 21471 in 94930d4

	urandom = {
	email = "colin@urandom.co.uk";
	matrix = "@urandom0:matrix.org";
	github = "urandom2";
	githubId = 2526260;
	keys = [ { fingerprint = "04A3 A2C6 0042 784A AEA7 D051 0447 A663 F7F3 E236"; } ];
	name = "Colin Arnott";
	};

https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aopen+involves%3Aurandom2

[winterqt]

How in the world did you manage to try to "decomissionate" someone who made a PR two days ago? Do you even try to see if someone is actually inactive before making these PRs?

[AndersonTorres]

How in the world did you manage to try to "decomissionate" someone who made a PR two days ago? Do you even try to look before you leap?

Usually I do not care about aggressive behavior, because I am not aware of subtexts most of time.

However, this is our second interaction in a little more than a month in which you did not spare harsh words in rebuking my reprehensible behavior, while taking the least charitable interpretation available.

Is there anything I can do to amend my failures on our interactions?

[bendlas]

@AndersonTorres this level of carelessness is not what I'm expecting to see, when approaching an issue where we as a community essentially say to a person: "We don't need you any more, you can go"

• You created an issue without linking to any related conversations, and when this is pointed out to you along with a suggestion for a connecting RFC, your response is essentially "eh, different thing" without clarifying any connex or difference and how such difference would affect your judgement (and AFAICT, all of this so far is based on your judgement alone)
• When your (duplicate?) issue failed to attract much engagement, you just went ahead and created a bunch of PRs for kicking people out, in which you don't even link back to your new issue (from the perspective of a maintainer targeted such, that must feel very discouraging and willful)
• Where the discussions around RFC55 seem to be very mindful around the human side of such a push, worry about how to make it clear to people that they'd be welcome back in the future, even going so far as to create a "retired" team. You seem mostly oblivious even putting a "thank you for your service" just as an oh-btw - afterthought.
• Why are we even focussing on kicking out maintainers? I can get committers, since those are security-relevant. But the only downside of an inactive maintainer, is that they might not respond to pings at a given time of the year. I would argue that your effort to "clean up" here is actively harming the community, because even an inactive maintainer may contribute their knowledge at times, or somebody may have luck contacting them when dealing with an especially tricky situation.

I have been less active in nixpkgs at times and I can tell you for sure that I'd have been greatly offended if I woke up to some rando removing me from my packages and the organization, without even proper community backing.

I understand if there is a language barrier when trying to communicate effectively, but this is not a simple technical issue, where we can easily fix stuff afterwards, or play around with changes.

Therefore, in an abundance of caution, I'll close down your other related PRs for the time being and I'll ask you to work in a more consensus - oriented fashion, if you feel you have to question people's roles with the project in the future.

[bendlas]

@superherointj since you seem to disagree with closing down the PRs where approval by the targeted maintainers had been given, would you mind sketching out what benefit you see in removing maintainers at all?

[superherointj]

would you mind sketching out what benefit you see in removing maintainers at all?

Users ask maintainers for reviews and wait long for reviews that never materialize.

Committers have to wait for package maintainers to answer for a week even which delays merging PRs. See: https://github.com/NixOS/nixpkgs/tree/master/maintainers#definition-and-role-of-the-maintainer

It's best to know no one is taking care of a package. On breakage, instead of forever spending build resources, the package should be removed, since no one cares about it.

[thiagokokada]

Let me reply a few of those points that I think it is relevant considering I merged some of those cleaning up PRs.

* Where the discussions around RFC55 seem to be very mindful around the human side of such a push, worry about how to make it clear to people that they'd be welcome back in the future, even going so far as to create a "retired" team. You seem mostly oblivious even putting a "thank you for your service" just as an oh-btw - afterthought.

Yes, +1 for being grateful for those that did some job in nixpkgs. But I think we also need to keep in mind that @AndersonTorres is a human like any other, and putting pressure on they without further discussion (and closing their PRs preemptively, again, without at least some discussion) is not the kind of reply I expected from someone that is against the idea.

* Why are we even focussing on kicking out maintainers? I can get committers, since those are security-relevant. But the only downside of an inactive maintainer, is that they might not respond to pings at a given time of the year. I would argue that your effort to "clean up" here is actively harming the community, because even an inactive maintainer may contribute their knowledge at times, or somebody may have luck contacting them when dealing with an especially tricky situation.

There are a few downsides of an inactive maintainer that I can think:

• They have moderation powers inside the nixpkgs repository. Yes, this means they can't merge code per see, but I wouldn't say there is zero risk of keeping maintainers account indefinitely
• This also makes the process of reviewing and merging PRs more difficult. It is really difficult to merge a bump PR since you never know if the maintainers are active or not. Some maintainers get really aggressive when you merge something without their blessing (not going to expose anyone here, but if you want examples ask me in Matrix or somewhere else), so knowing that "everyone that is maintainer in this package is actually active" would be useful

Also, I disagree about the part of "actively harming community". If the member ever wants their maintainer bit back, they can be re-added. Again, I agree that maybe this should be more clear, probably putting a message in the PR making it clear, e.g.: "if you ever want to come back @someone, just open another PR and feel free to link this issue, and your maintainer rights should be restored ASAP".

I have been less active in nixpkgs at times and I can tell you for sure that I'd have been greatly offended if I woke up to some rando removing me from my packages and the organization, without even proper community backing.

I think this is mostly a communication problem. We definitely need to have a guideline on how to do those kind of clean-ups, but I still think, IMO, we should have them often.

[AndersonTorres]

@AndersonTorres this level of carelessness is not what I'm expecting to see, when approaching an issue where we as a community essentially say to a person: "We don't need you any more, you can go"

This is neither the intention nor the message those pull requests are passing.

This is a practical issue: there are maintainers not interacting with Nixpkgs in a long span of time.
The most immediate effect is that it brings a misleading impression that some packages are being maintained and cared by someone when they are not.

• You created an issue without linking to any related conversations, and when this is pointed out to you along with a suggestion for a connecting RFC, your response is essentially "eh, different thing" without clarifying any connex or difference and how such difference would affect your judgement

The issue pointed by emilylange deals mostly with commit status.
Albeit being related with the issue I opened, they deal with different scopes (even because commit privileges floating around bring some security challenges), and they can run mostly in parallel.

I gave a terse and direct answer to emilylange, not because I dismissed his information as not important, but because it was orthogonal.
I did not feel the necessity of over-explaining this orthogonality.

(and AFAICT, all of this so far is based on your judgement alone)

As I said above, it is a practical issue: maintainers not interacting with the codebase in a long span of time.

• When your (duplicate?)

As I said above, not duplicate but orthogonal.

issue failed to attract much engagement,

I disagree on both accounts:

1. the issue attracted a non-negligible amount of engagement
2. an issue does not necessarily need to attract a critical-mass amount of engagement in order to be worked out

However, I will not elaborate here - since I will close the main issue.

you just went ahead and created a bunch of PRs for kicking people out,

My intention is not a violent kick as your wording is suggesting here.
Again, it is working about the practical issue of packages being maintained in name only.

in which you don't even link back to your new issue (from the perspective of a maintainer targeted such, that must feel very discouraging and willful)

This was a failure from my part.
In order to not generate a flood of pings, I did not past the link in the commit message.
Usually I put them in a reply, via web interface.

However I was careless in recent PRs by not doing this upfront.
Apologies for this.

• Where the discussions around RFC55 seem to be very mindful around the human side of such a push, worry about how to make it clear to people that they'd be welcome back in the future, even going so far as to create a "retired" team.

To be honest, I never thought this is necessary. To me, in Nixpkgs anyone is welcome by default.
Nixpkgs is a very rare case of a warm, welcoming community, with a low barrier of participation - I dare to say, a very open doors policy.
People do not need to do more than sending a PR in order to contribute - and we even provide a mail thread when people can contribute with patches.

You seem mostly oblivious even putting a "thank you for your service" just as an oh-btw - afterthought.

I did this in some cases when the person answered the PR, not as an afterthought but as a sincere acknowledgement.
Apologies for my terseness.

But the only downside of an inactive maintainer, is that they might not respond to pings at a given time of the year. I would argue that your effort to "clean up" here is actively harming the community, because even an inactive maintainer may contribute their knowledge at times, or somebody may have luck contacting them when dealing with an especially tricky situation.

As I said before, despite recent events, Nixpkgs is very welcoming.
Any of these retired maintainers are fully free to contribute, and they do not even need an entry in maintainers-list.nix to contribute.
Therefore, the cleanup is still useful.

Since I will not disagree with your final paragraphs, I will not pursue this further.

[AndersonTorres]

Oh I almost forgot this:

I can get committers, since those are security-relevant.

Maintainers are also security-relevant. A maintainer is formally invited to the team, having some mild moderation powers.
What if some of these maintainer accounts that did not touch Nixpkgs in years was hacked and started deleting a truckload of open PRs? I think it would be a non-negligible security concern.

Just to be sure, you, in an abundance of caution, closed my other PRs. So the possibility exists.

---

Especifically for @urandom2
I made an error of judgement by overlooking your most recent commit in my local Nixpkgs repo.
My sincere apologies for not being careful.

[thiagokokada]

Why are we even focussing on kicking out maintainers?

Can I ask honest ask the reason why we are focusing in keeping inactive maintainers? From what I understand (and I may be wrong), meta.maintainers were created as a mechanism so folks can be involved in the process of maintaining packages (e.g.: bumping, testing, fixing issues, etc.) without needing for us to give commiter access to everyone (since this would reduce security).

However, by keeping inactive maintainers, we can't rely in this mechanism anymore since there is no guarantee that pinging a maintainer will get an answer.

It does seem to me that we are relying in maintainers right now mostly as a "reward" for those that ever had a contribution to nixpkgs. So if you ever get to the point that you can open a PR, congratulations, you can add your name to maintainers-list.nix and have your name there forever. At least this is the impression I get if we commit to never remove a maintainer, because if we keep creeping up inactive maintainers, eventually nobody will bother trying to ping maintainers anymore, since most of the time the person will be inactive.

[thiagokokada]

this level of carelessness is not what I'm expecting to see

Here is one example that the even the maintainer concur that they're inactive: #330232 (review) (not sure @bendlas you decided to ping the maintainer again in this instance).

You can see that even sometimes the maintainer themselves concur that they should be removed. Maybe they don't want to bother to open a PR (this is clearly the case here) or even answer the topic because they don't remember their password account/lost access to e-mail for example. But I still think we should be removing those cases.

Again, if they ever want to come back, they should feel free to do so.

[bendlas]

REMARK I mixed quotes from different people in this reply, please don't nail me to it. I tried to keep each answer self-contained.

Can I ask honest ask the reason why we are focusing in keeping inactive maintainers?

I already gave one reason: even an inactive maintainer may contribute their knowledge at times, or somebody may have luck contacting them when dealing with an especially tricky situation.

Another one is, that being in maintainers-list.nix will be a point of pride for anybody who made it in there and make it much easier to activate them again in the future.

Maintainers are also security-relevant.

A fair enough point. Also a few other good points, all around. And yet, a PR for removing somebody is still not the place for making them.

where we as a community essentially say to a person: "We don't need you any more, you can go"

This is neither the intention nor the message those pull requests are passing.

It is at least part of the message, though. No matter how much legitimacy the process has (which in this case it didn't), that message will always be part of the mix. Which is why I want us as a community to deal with this with matters like this in the most mindful and empathetic way possible.

I did not feel the necessity of over-explaining this orthogonality.

Even when looking at everything I could find (let alone just looking at this PR) I didn't feel at risk of being over-explained to. In fact, I would have wished for some reasoning (e.g. many of the arguments now made in these comments). Was there a link to an RFC that I might have missed?

• When your (duplicate?)

As I said above, not duplicate but orthogonal

Not fully orthogonal either: There may be many differences between contributors and maintainers, but a few similarities remain:

• there are people that these roles refer to
• who we ask to provide resources to the community as part of fulfilling their roles
• who take pride in having fulfilled their roles and will take pride if fulfilling their roles in the future

We need to be aware of this dimension when asking people to step out!

(and AFAICT, all of this so far is based on your judgement alone)

As I said above, it is a practical issue: maintainers not interacting with the codebase in a long span of time.

I can empathize with getting frustrated over the RFC not moving forward and wanting to take matters into your own hand. However, there is a reason that people felt the need to do an RFC around an issue very similar to this: This is not about just another list in source code: This is about just another list in source code with human names on it.

Why not at (the very) least publish the method that you use for selecting the people that you want to take off the list?

this level of carelessness is not what I'm expecting to see

Here is one example that the even the maintainer concur that they're inactive: #330232 (review) (not sure @bendlas you decided to ping the maintainer again in this instance).

I appreciate your use of irony. I'll repeat my explaination from one of the closed PRs here: Any reasonably polite person would say "sure, count me out". The fact that this was never properly discussed or decided, invalidates the whole process.

In essence, I was trying to make a point of inviting people back in, when they might have felt pressured to agree without due process.

putting pressure on they without further discussion (and closing their PRs preemptively, again, without at least some discussion) is not the kind of reply I expected from someone that is against the idea.

Again, appreciate the irony. And again I did what I did in attempt to undo some of the damage I saw in front of me and to take the opportunity to make it into an invitation to contribute again.

As I said before, despite recent events, Nixpkgs is very welcoming.

I'd argue that asking people to leave in such a careless way, is making it less so.

Therefore, the cleanup is still useful.

See, here is something I'm honestly not getting: If we deem it necessary to tidy up. Why not go the extra mile to make sure that people know what is what, when they are removed from a list? Why go with bland statements like Since xxxx is inactive. (or not even that), while leaving a default PR template in? Why not at least type out a standard text block, thanking people, telling them that they're welcome back any time, referring to a well-reasoned issue (which #290642 is not, even if you do "not feel the necessity of over-explaining"), maybe even taking the time to list their contributions?

Also about the usefulness of this cleanup: In #290642 (comment), you state They should be listed, formally retired and their packages put to adoption.. OK. Has this work been done as part of the PRs?

Here #290642 (comment) you state

I am cogitating another idea: mark them as inactive at maintainer-list. Abandoned idea.

Have you written out this deliberation of yours somewhere? Because that's What I would have suggested.

I imagine an active flag on a maintainer would actually be very useful:

• it would encourage them to start contributing again, to get that active back, instead of alienating them by erasing their contribution mark
• it would allow a bot to post something like It seems you pinged XXXX, who has unfortunately been inactive lately, please consider finding more eyes to look at this. This issue/PR has also been automatically escalated to the nixpkgs adoption agency. Thank you for your patience
• we could still take away their moderation powers, while they're not active, while keeping the recognition for as long as we keep the package

---

There would be more to respond to, but I'll stop now. I hope that my stance is clear: I'm not against cleaning up our maintainers list, per se. But I would like us to at least leave an appropriate paper trail, when having to do the open-source equivalent of HR, and better yet, actually take the human element into consideration -- which we can do precisely because we're not about money.

[AndersonTorres]

It is at least part of the message, though.

The "kick as a putrid corpse" spin you are conveying here - it is not.

Another one is, that being in maintainers-list.nix will be a point of pride for anybody who made it in there and make it much easier to activate them again in the future.

I am was not interested on deleting entries on maintainers-list.nix.
As I said, the issue is around packages maintained in name only.

I can empathize with getting frustrated over the RFC not moving forward

Since we are talking about barriers of communication here, I dare to disagree.

RFCs are reserved for structural changes - as explained in the README, section When this process is followed.
Orphaning packages is arguably not a structural change in Nixpkgs.

On the other hand, not a long time ago, in a heated discussion I suggested that adding meta.repository should be the subject of an RFC.
Among other arguments, it was dismissed because RFCs are slow and tiresome and frustrating.
(And I can't censor them - from what I found around, this is a general feeling that is brought about time after time.)

Well, the code adding meta.repo was merged. Maybe RFC process was unneeded after all...

Oh! A couple of weeks later it was reverted because it caused a bug that broke evaluation of some closed-source binary-only packages.
Who would have thought...

Why not at (the very) least publish the method that you use for selecting the people that you want to take off the list?

I was initially polishing some ideas for a shell script, but it was basically filtering people with commits older than a threshold, like 12 or 18 months. This can be done in a local checkout of code.
After that, some filtering on GitHub API would be useful to clean up, but it would require extra code for dealing with anti-flood measures...

Why not at least type out a standard text block, thanking people, telling them that they're welcome back any time

It would be a nice idea!

Has this work been done as part of the PRs?

Some packages were adopted while I did some cleanups.
An issue about adopting critical packages was opened too: #327779

Have you written out this deliberation of yours somewhere? Because that's What I would have suggested.

Feel free to suggest it again: #310759

[superherointj]

The problem I see in nixpkgs:

• thiagokokada, 2275 reviews merged
• AndersonTorres, 2055 reviews merged
• superherointj, 1569 reviews merged
• bendlas, 75 reviews merged

There are things you can only understand with experience. There is a reason the active reviewers/commiters want to get rid of inactive maintainers. It doesn't help!

Since you claim there isn't consensus in favor of removing INACTIVE maintainers. And I'm quite tired of nixpkgs by now. I'm out of this madness. Good luck pleasing your inactive maintainers.

Feel free to review my PR removing myself. Since we disagree about direction of things. And I'm honestly too tired for everything negative comings from nixpkgs. The amount of negativity I receive from here is surreal. Also, this is not your fault. It is just that I don't want to continuously live sudden crisis that require having to debate everything until exhausting for bad reasons. Or be blamed for anything. My reasons. No worry. I'm not merging anymore PRs. Peace.

Update: I'm sorry for pointing out the stats like that. I guess, I was mad. My bad. I ask for forgiveness.

[bendlas]

It is at least part of the message, though.

The "kick as a putrid corpse" spin you are conveying here - it is not.

I know it's not meant as such. It's still a credible emotional worst-case scenario for somebody on the receiving end.

And the more I think about it, the more I actually do find the erase the contribution mark while keeping the fruits of labour - angle kind of disgusting, even while I know that the maintainers field is not for contribution marks.

Another one is, that being in maintainers-list.nix will be a point of pride for anybody who made it in there and make it much easier to activate them again in the future.

I am was not interested on deleting entries on maintainers-list.nix. As I said, the issue is around packages maintained in name only.

See, even this in name only selection, that I keep seeing, strikes me unnecessary (borderline toxic, in fact). We aren't interested if somebody got a cheap github credential through a small nixos contribution (in fact, more power to them).

We are interested in whether we can expect somebody to react to issues and PRs that they might be pinged into. Or if it's time to start advertising an open maintainership for a package, to the users of that package (which is, btw, a much gentler way to find new maintainers, than to delete stuff out from under them).

And even if we end up deleting packages: Isn't the information who used to maintain them, valuable until the very last second?

I can empathize with getting frustrated over the RFC not moving forward

Since we are talking about barriers of communication here, I dare to disagree.

If your point is that I could have stepped into the RFC process at any point: Touché!

RFCs are reserved for structural changes - as explained in the README, section When this process is followed. Orphaning packages is arguably not a structural change in Nixpkgs.

Establishing a process for phasing out software and people from the organization arguably is, though. And by getting started on removal PRs, you did exactly that.

Look, I'm not even about the RFC, necessarily. What I am about is treating people with dignity (yes, kill me for the irony). And when dealing with human names on lists, it is imperative that we operate transparently, even-handedly, and with explicit intent. People can easily get touchy about group memberships, believe it or not. Tons of subtext involved.

And saying goodbye is always hard, even if it has been a few years. Whole documentation pages have been written and subsequently ignored for much less.

Why not at (the very) least publish the method that you use for selecting the people that you want to take off the list?

I was initially polishing some ideas for a shell script, but it was basically filtering people with commits older than a threshold, like 12 or 18 months. This can be done in a local checkout of code. After that, some filtering on GitHub API would be useful to clean up, but it would require extra code for dealing with anti-flood measures...

Yeah, but like .... how did you do it? Or rather: Do you agree that it's important to let people know how they were selected for removal? Even if it's just an english sentence of the criteria you used?

Can you imagine how the criteria that are being communicated at that point, are the criteria that the person will seek to fulfill in case they want to be let back in? And so if their criterium was somebody named Charlie opening up a removal PR without further elaboration, how they could easily see no choice other than to go to Charlie personally and beg him to let them have their maintainership back?

Some packages were adopted while I did some cleanups. An issue about adopting critical packages was opened too: #327779

OK, good to know they weren't just abandoned. This information would btw also be nice to pass to someone, who's being replaced as a maintainer for a package: Who is stepping up for it.

Feel free to suggest it again: #310759

You know what? I will!

[emilazy]

While clearly there is nuance to how to go about dealing with inactive maintainers, and obviously this PR was totally incorrect, I think there is no rational reason to keep maintainers around when they have signalled agreement with their removal. Maintainers are allowed to remove themselves! I don’t think @bendlas’s unilateral closures of PRs where the inactive maintainers approved them were at all appropriate and I hope those PRs can be revived.

We have an opt‐in eval warning for unmaintained packages for a reason. We have an RFC for removing unmaintained and broken packages for a reason. When a maintainer list contains names but those names are not active in the project and won’t respond to pings, the package is effectively unmaintained. Leaving names in there and expecting people to just know – or spend time looking up – who isn’t active makes the maintenance problems in the tree less legible, both to human contributors and to the policies and automated systems we have built up around packages being unmaintained.

[bendlas]

I don’t think @bendlas’s unilateral closures of PRs where the inactive maintainers approved them were at all appropriate

You don't think my "due process" argument, has any merit, and that without any information about the "how" and "why" somebody might feel pressured to say "sure, remove me", instead of feeling encouraged to step back up?

[emilazy]

Anyway, it’s really unfortunate that we have lost an active committer over this PR and I hope we do not lose any more. While there is clearly scope for legitimate disagreement here, please consider if this matter really needs more 10‐paragraph replies with every sentence from the previous messages quoted and responded to…

I hate to be blunt, but given the patterns at play here I think it is necessary:

@AndersonTorres, you really need to get better at taking feedback on your actions and attitude in Nixpkgs. I’ve seen many people try to do so in various different ways but I’ve not seen your behaviour change as a result of any of it. You make a lot of valuable contributions to the project, but people find you difficult to work with, and I know there are multiple people who have burned out on the project in part because of your interactions.

@bendlas, this isn’t the first or second thread I’ve seen recently that became full of heated and very long back and forth messages going nowhere once you jumped in. Please try to contribute more light than heat. You’re talking about being welcoming and not offending contributors, but if you can’t keep civil and avoid hostility that rings hollow.

[bendlas]

@bendlas, this isn’t the first or second thread I’ve seen recently that became full of heated and very long back and forth messages going nowhere once you jumped in. Please try to contribute more light than heat. You’re talking about being welcoming and not offending contributors, but if you can’t keep civil and avoid hostility that rings hollow.

@emilazy while I appreciate that you're saying that you find my arguments too heated and my methods to crass, I'll ask you to not derail this conversation (admittedly happening on an already derailed PR) by going meta like this.

I'll be happy to answer for anything that you or anyone may feel I need to answer for, in a new thread, be it on discourse or zulip. It should also be easier to establish patterns this way, no?

Anyway, it’s really unfortunate that we have lost an active committer over this PR

Did we? I thought they already reconsidered when they deleted their comment, while I was typing out my plea for them to stay ...

EDIT oh, I see it now

[bendlas]

The problem I see in nixpkgs:

• thiagokokada, 2275 reviews merged
• AndersonTorres, 2055 reviews merged
• superherointj, 1569 reviews merged
• bendlas, 75 reviews merged

@superherointj it's clear to me, that I've hurt you with something, so I'll not ask any further questions about this. But that is low. My number of reviews merged, that is.

There are things you can only understand with experience. There is a reason the active reviewers/commiters want to get rid of inactive maintainers. It doesn't help!

See, that pain that I'm hearing through this statement. I understand it. I've felt it. It's not a good basis for decisions. I've always been a big fan of stepping away, touching some grass and coming back refreshed.

Since you claim there isn't consensus in favor of removing INACTIVE maintainers.

Well, is there? How does the consensus say it's supposed to be done? Can I read about it? Why didn't we link it in the PRs that were opened?

And I'm quite tired of nixpkgs by now. I'm out of this madness. Good luck pleasing your inactive maintainers.

Feel free to review my PR removing myself. Since we disagree about direction of things. And I'm honestly too tired for everything negative comings from nixpkgs. The amount of negativity I receive from here is surreal. Also, this is not your fault. It is just that I don't want to continuously live sudden crisis that require having to debate everything until exhausting for bad reasons. Or be blamed for anything. My reasons. No worry. I'm not merging anymore PRs. Peace.

You know, that comparison that you drew up there, between our numbers, I found that kind of hurtful. So I'm a little bit mad at you as well right now. So I'll not review your PR now. Feel free to ping me if you still want to leave in a week. I hope you'll reconsider staying.

[winterqt]

Is there anything I can do to amend my failures on our interactions?

There are better venues to have this conversation (feel free to email me or PM me on Matrix), but my frustration boils down to this:

@AndersonTorres, you really need to get better at taking feedback on your actions and attitude in Nixpkgs. I’ve seen many people try to do so in various different ways but I’ve not seen your behaviour change as a result of any of it. You make a lot of valuable contributions to the project, but people find you difficult to work with, and I know there are multiple people who have burned out on the project in part because of your interactions.

You're right that I probably shouldn't use such harsh words, but when your interactions with the project have never changed as a result of many comments from many people, I have no reason not to.

[emilazy]

@emilazy while I appreciate that you're saying that you find my arguments too heated and my methods to crass, I'll ask you to not derail this conversation (admittedly happening on an already derailed PR) by going meta like this.

I'll be happy to answer for anything that you or anyone may feel I need to answer for, in a new thread, be it on discourse or zulip. It should also be easier to establish patterns this way, no?

No, thank you. I think someone had to say something and the behaviour from both parties here demanded comment but I’m content to have tried and I don’t think it’s my role to get into the weeds about this with you when you’ve already been warned about this kind of conduct recently by a member of the moderation team.

[superherointj]

@superherointj it's clear to me, that I've hurt you with something, so I'll not ask any further questions about this.

You have not hurt me. What I can't handle is the amount of extra-work, back-tracking happening in nixpkgs, necro-bumping and second guessing. The more contributions, the more the odds of someone digging up something and starting a thread arguing whatever and then being forced to participate/answer in a crisis mode. Also, no merit. Then we end up in this situation that, people claim whatever, and whatever so be it. Say the words, RFC, 'consensus', process and nothing moves forward ever. And people that have put the work gets punished many times over. (Not that I am putting that much work, I stopped long ago, other people do a lot more than me, I'm a minor contributor). I'm just trying to explain the issue.

But that is low. My number of reviews merged, that is.

Well, I don't know what you mean by that. I only tried to convey the idea that people that have reviewed more think differently. A better awareness of pain points. And then, those 'useless PRs' are actually meaningful considering the amount of 'ghosting' we see.

See, that pain that I'm hearing through this statement. I understand it. I've felt it. It's not a good basis for decisions. I've always been a big fan of stepping away, touching some grass and coming back refreshed.

I honestly don't know.

Well, is there? How does the consensus say it's supposed to be done? Can I read about it? Why didn't we link it in the PRs that were opened?

Well, ... I'm tired, so I'm no longer interested in discussing what should/shouldn't be. People usually think 'rigidity' is a solution, but then, it also doesn't work as well as people think. The more bureaucracy there is, the harder it is for those that actually doing the work. I don't know the right answer. Things just feel miserable.

You know, that comparison that you drew up there, between our numbers, I found that kind of hurtful.

Just facts. If you want to be really hurt, see @SuperSandro2000, and he got suspended and had a lot of trouble to get back. lol
+12.000 reviews merged, Sandro is not a bot! He is a real person! lol

I only used that to try to convey why the difference in thinking. One is trying to optimize for what is best for whom is active. You wanted to optimize for the inactive. Time is scarce resource. You took time from me today, that I have to answer all these messages, read, think, etc. (And vice-versa.) It's a trade-off. Things won't be perfect.

So I'm a little bit mad at you as well right now.

I'm not mad at you. I'm at peace. I invite you to calm yourself. And just reflect about whatever is bothering you. Then, grow wiser. (This is a general solution for such problem.)

So I'll not review your PR now.
Feel free to ping me if you still want to leave in a week. I hope you'll reconsider staying.

I won't be staying, but not because of you specifically, I understand you had your reasons to try to move things to a certain direction. That makes sense for you. I just can't handle nixpkgs anymore because I don't have the bandwidth for it. I was already 'slowing down' before you pinged me 10x today (lol. You went over that many PRs and re-posted the same messages.)
So yeah, I need to leave nixpkgs anyway. For many reasons, I don't have the time/energy/motivation/etc. It's such a distraction for me. And there other pressing issues. So I kinda need to be out of this.

I'm all good. I hope you are well too.

Btw, I like Anderson Torres here. And I never had any communication problem with him. I think, it is a bit unfair the much bashing he gets. I think, often people misread things.

No bad feeling from me about anything. I'm just at my edge here. Just that.

I wish you all the best. And I hope you contribute more than Sandro ever did. Then, you laugh at us with our humble stats. :-)

Best regards.

[adamcstephens]

Even if you can bypass the lock, please consider if this is the best venue to spend your time and energy. We won't solve these problems buried in a random PR.

[thiagokokada]

Even if you can bypass the lock, please consider if this is the best venue to spend your time and energy. We won't solve these problems buried in a random PR.

Sorry to bypass the lock, my last reply in this discussion. Anyone that wants to discuss this further, please ping me on Matrix, not that this will happen, because I think the objective was already done (derailing an otherwise peacefully clean-up of maintainers that don't care about nixpkgs to discuss yet another process that will probably never gain traction).

And yes, I concur with @superherointj and @AndersonTorres here that we don't need a RFC for everything: sometimes we just need a few people that have strong desire to improve the situation. But that is my rant, I digress, let's back on-topic.

I already gave one reason: even an inactive maintainer may contribute their knowledge at times, or somebody may have luck contacting them when dealing with an especially tricky situation.

I contribute for a bunch of open source projects and have a few of my own (they're definitely not big or anything). I also work as a professional developer for at least 8 years. If someone asks me about a piece of code that I contributed 6 months ago and didn't touch it anymore, there is a good chance that I will just say "I don't remember". However, if I am still interested on it, I will definitely say something.

I think this is way more likely to be the case with an inactive maintainer: even if they want to contribute, they have nothing to add to the discussion because they don't remember anymore. It is also very common for inactive maintainers that they stopped using the package in case or even nixpkgs at all.

I don't think expecting maintainers show that they're still interested in the package by replying a (friendly) call if they didn't contribute in the last X months, something like:

"Hey @someone, are you still interested to collaborate in nixpkgs? Otherwise we will remove you in 1 week, but please keep in mind that you're welcome to come back if you want."

Keep in mind this is an example, the wording could be improved.

Another one is, that being in maintainers-list.nix will be a point of pride for anybody who made it in there and make it much easier to activate them again in the future.

I really don't think we should use maintainers-list.nix as a "point of pride". It is not free to keep the list growing without ever cleaning it up. I can think a few reasons here:

• Big files slows down lots of editors making it difficult to contribute, especially for newcomers that may have no clue on how to optimise their editor configuration
• This also probably has some implications in eval times. I wouldn't say huge, but we are already having performance issues in nixpkgs in general and I am sure a ~500kb file doesn't help here
• Again, the security issue part since AFAIK being in the maintainers-list.nix is how we invite someone to the @NixOS/nixpkgs-maintainers group in GitHub (and give them moderation powers, that again, can be a security risk)

See, that pain that I'm hearing through this statement. I understand it. I've felt it. It's not a good basis for decisions. I've always been a big fan of stepping away, touching some grass and coming back refreshed.

There is no problem of stepping out. We are not removing maintainers forever. If they ever want to come back, the process is exactly the same as it was: open a PR adding themselves to maintainer-list.nix, add themselves to a few packages, done.

You know, that comparison that you drew up there, between our numbers, I found that kind of hurtful. So I'm a little bit mad at you as well right now. So I'll not review your PR now. Feel free to ping me if you still want to leave in a week. I hope you'll reconsider staying.

@superherointj did a honest comparison to show what a person that is a long time in nixpkgs has as a vision vs. a newcomer, and even if maybe it was not the best way to do so, it is still a valid argument that if we want to have a proper discussion, should be considered.

What I mean by that is that someone that is longer in nixpkgs will probably have more context about the kind of issues a package having inactive maintainers will have them someone that is new. But this is not to make your contributions lower or anything @bendlas (I don't know you and this is my first interaction with you AFAIR).

So again, while we are talking about the human aspect here, I think we should also consider how people replying here are also human and consider this instead of making the whole reply about one point.

---

Edit: keep in mind that I put my professional and open-source experience there not to say that I have more say in this matter than anyone or anything like that. The only reason I put it there is that I think with experience you get to... experience more things, that's it. I don't think people with more experience are necessary more technical or anything like that (I even know some people that has less experience than me that I consider more technical), but having more experience helps in cases like "getting in a heated discussion with a maintainer because I merged a PR without the maintainer approval because I can't just trust that the maintainer is active or not by looking at the maintainers-list.nix".

I seriously considered creating a spreadsheet of active maintainers (yes, this looks as crazy as it sounds) before deciding it was best to stop contributing to Nixpkgs for a while, same as you @bendlas, but I definitely wouldn't feel bad if someone decided to remove myself from Nixpkgs at the time.