Maintainers leaving Nixpkgs

UPDATE: The Milestone was removed and seemingly replaced with a label: Pull requests · NixOS/nixpkgs · GitHub

https://github.com/NixOS/nixpkgs/milestone/27

7 Likes

This post was flagged by the community and is temporarily hidden.

6 Likes

What’s the purpose of this kind of doomsaying comment?

18 Likes

It seems the milestone was deleted.

Thanks for the heads up, seems like they added a new issue label instead

https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+label%3A"8.has%3A+maintainer+removal"

I’m no longer a member of the NixOS GitHub org so I can’t help with the labeling :person_facepalming:

2 Likes

Yes, I deleted the milestone, because I feel that milestones are complex tasks we are collectively striving toward. They should be things we want to happen. We are not striving to push maintainers away. The label should be able to track it for people that want to track it.

25 Likes

Maybe I’m out of the loop, but why are nixpkgs maintainers leaving? The whole open letter is mostly about nix (CppNix) leadership. AFAIK, that leadership has little to do with the nixpkgs project.

5 Likes

See the post linked in Leave the Determinate Systems community by danderson · Pull Request #307033 · NixOS/nixpkgs · GitHub; I won’t do a better job than that ex-maintainer at explaining why some people are reacting to that post in this way.

3 Likes

Does Determinate Systems control Nixpkgs/NixOS(module system)? Apparently no.

So if Canonical once implied that they control Debian, and confused the Debian community with Ubuntu, as an angry Debian maintainer, would you leave the Debian community?

Eelco Dolstra has made almost no contribution to Nixpkgs in the past three or four years, except for providing reference opinions for Nix version upgrades. At the same time, Eelco Dolstra cannot control Nixpkgs in any way other than being the header of the organization. Especially now that Tvix is ​​mostly compatible with Nixpkgs except the flake.nix lying inside.

Control of Nixpkgs, if you need to understand it that way, is currently managed by the Nixpkgs committer team. I believe this is already pointed out in CONTRIBUTION.md or other documents it links to, and you are expected to read these documents carefully before contributing.

I don’t think committers have the same qualities as the other teams we generally criticize. Our appointments are transparent to the community. Anyone can join publicly, or publicly accuse team members, and so far, I have not seen any examples where these demands have not been properly handled. Most abuses of the “commit bit”, or the right to speak, have been addressed, but if some have not, you are welcome to point them out.

The current organizational structure of NixOS Organization does need to be adjusted, and I recognize the rationality and urgency of this issue. But I beg everyone not to express disapproval against the foundation or anything by removing their own maintainer entries, or remove entries because they are tired of arguing. You’re not hurting the people you’re trying to hurt, but you’re spreading fear into a real segment of the “community”. Things don’t work this way.

I hope our joint efforts in the past will not become less qualified because of these episodes. As a committer who has just started working for a month, I have spent several hours after class and homework every day, to click on “first time contributions”, and “has package: new” label, and try to give valuable reviews and provide clues as much as possible. As a maintainer who currently maintains 63 packages, I hope that my upstream can innovate with me together, and other users can benefit from it well, instead of sending me into a panic of not knowing what to do.

Yesterday night I worriedly scrolled through almost all the relevant comments and read almost all the attached links until 5 am the morning. After waking up at 1 pm today, I spent almost the entire afternoon and evening reviewing, testing and merging, hoping these disputes will not hinder the progress of Nixpkgs.

If you are dissatisfied with the status quo, I hope you can personally participate in these discussions. If you already feel burned out, you can leave Nixpkgs temporarily and work on some other technical projects, or go to Youtube to watch some funny videos. I hope this incident is the beginning of a better community, rather than a trigger for disbandment with resentment.

Some of my words have been translated by Google Translate. While I have made manual modifications, the wording may still be inaccurate, please forgive me.

50 Likes

Personally, I have the intention of continuing to try to contribute to NixOS and Nixpkgs as possible, wherever things fall, because I think NixOS and Nixpkgs are important enough that things will be sorted out eventually. Honestly, I don’t really want to take part much in the discourse (and I suspect nobody really wants to, of course) but I have been tracking it loosely to try to make up my own mind and make sure that I have enough awareness to know where I stand. I am not thrilled with how everything has been handled, but it is what it is, and I’ve come to terms with the fact that the moderation team has been faced with some extremely difficult situations, dealing with problems that simple rule enforcement can’t cover, with highly charged topics and very vocal and emotional people. It’s definitely sucked, and there’s a lot of people I respect that I am not seeing fully eye-to-eye with right now, which isn’t a great feeling. But, again… it is what it is. Nothing to do but try to move forward.

On a more pragmatic note… It’s clear that a lot of highly valuable contributors have left the project. This is definitely a huge problem for the sustainability of NixOS, which already feels very strained for maintainers. I hope that some of them will consider coming back in the future, but until then, I have decided to try to look through recently-orphaned derivations that might be things I can ‘adopt’, particularly packages that I either use or have domain experience with. Maybe there should be an effort to get maintainers for important packages? I think sudo was recently orphaned, that seems pretty bad, although I’m hesitant to step up for something so important as a currently small-time maintainer.

20 Likes

If maintainer changes want to be tracked then the label should be has: maintainer-list change then the auto-labelling action can be used, the label could also be used to track new contributors who also add themselves to maintainers!

The current label is a bit useless due to the github search having the in:title option

4 Likes
2 Likes

Even by adding the closed filter Pull requests · NixOS/nixpkgs · GitHub is still full of unrelated prs, please add back the maintainer leaving label

1 Like

Your search was wrong Pull requests · NixOS/nixpkgs · GitHub

To see maintainer removals then Pull requests · NixOS/nixpkgs · GitHub and if you wish to see only recent removals then Issues · NixOS/nixpkgs · GitHub because the labelling wasn’t applied retroactively

Labels are to avoid the inaccuracies of using title search.

For instance your recommended way to search for removals:

Includes a result that doesn’t belong:

Revert “maintainers/scripts/update.nix: Remove unicode from message”

1 Like

Not visible for me, if it was then maintainers\: would probably not show it.

I’m sorry, but this defeats the purpose of the label.

This was a Chesterton’s Fence type of label. It had a purpose. There was a specific intent in having the removals tracked independently. So “If maintainer changes want to be tracked” was the wrong assumption here. Tracking people leaving in the current time was the intent.

It’s also why it wasn’t done as a label initially: it’s original intent was more of a snapshot in time. A way to quantify what has happened without having to dig through all PRs and missing many because of differences in titles.

Sadly, GitHub does not provide any kind of good semantics to track this.

10 Likes

The milestone should have just been left up. Not all milestones in history are achievements.

10 Likes