Misuse of commit permissions

ckampka · November 20, 2020, 9:55am

I would definatly agree on that. I feel that the NixOS/-pkgs community could really benefit from a more active, maybe Debian-esque leadership system that gives the whole project some sort of focus an direction. That would make things a lot smoother imo.

7c6f434c · November 20, 2020, 10:29am

zimbatm:

Another aspect of this discussion is that the leadership group is relatively amorph. We have one BDFL. After that, some members of the community are more or less established. I am sure that the exact set will vary when asking different people.

I would definatly agree on that. I feel that the NixOS/-pkgs community could really benefit from a more active, maybe Debian-esque leadership system that gives the whole project some sort of focus an direction. That would make things a lot smoother imo.

This would be a lot of restructuring. The entire RFC process was painfully constructed to put the judgement calls on larger design decisions onto people who pledge to look into the details of the arguments carefully this specific time on this specific topic, and avoid demanding the same people to read up infinite amount of nuances about too many things.

ckampka · November 20, 2020, 11:27am

I don’t think those are contrary, I would argue that those are actually complementary.
Just because you strive for some general alignment, eg. “For 21.04, we want to focus on achiveing XXX” does not mean that you would not need a process to flesh out how to actually achieve this XXX, but it could defiantly help people prioritize where to focus their attention and effort.

7c6f434c · November 20, 2020, 11:55am

Just because you strive for some general alignment, eg. “For 21.04, we want to focus on achiveing XXX” does not mean that you would not need a process to flesh out how to actually achieve this XXX, but it could defiantly help people prioritize where to focus their attention and effort.

Nix* community is historically much better at working together despite being divided on basic priorities than at resolving sometimes literally reverse order of priorities based on vastly differing usecases, preferences and contexts.

danieldk · November 20, 2020, 11:56am

This comment was from jonafato and they are a maintainer of the package:

github.com

talyz/nixpkgs/blob/cfdeea41e668e786115195cb344e4d79b0cf210a/pkgs/applications/misc/keepassx/community.nix#L128


      
            preFixup = optionalString stdenv.isDarwin ''
              # Make it work without Qt in PATH.
              wrapQtApp $out/Applications/KeePassXC.app/Contents/MacOS/KeePassXC
            '';
          
          
  meta = {
              description = "Password manager to store your passwords safely and auto-type them into your everyday websites and applications";
              longDescription = "A community fork of KeePassX, which is itself a port of KeePass Password Safe. The goal is to extend and improve KeePassX with new features and bugfixes to provide a feature-rich, fully cross-platform and modern open-source password manager. Accessible via native cross-platform GUI, CLI, and browser integration with the KeePassXC Browser Extension (https://github.com/keepassxreboot/keepassxc-browser).";
              homepage = "https://keepassxc.org/";
              license = licenses.gpl2;
              maintainers = with maintainers; [ jonafato turion ];
              platforms = platforms.linux ++ platforms.darwin;
            };
          }

Unless I am overlooking something?

ckampka · November 20, 2020, 3:03pm

I cannot comment on “historically”, but the current state of nixpkgs suggests more a loss of control and nobody stepping up to take the wheel.

7c6f434c · November 20, 2020, 3:29pm

I cannot comment on “historically”, but the current state of nixpkgs suggests more a loss of control and nobody stepping up to take the wheel.

I am pretty sure that any attempt to step up and take the wheel will get a lot of pushback whatever the direction to steer is. Which is good.

danieldk · November 20, 2020, 3:30pm

First, I am not sure this is really going to work in a largely volunteer project. If you appoint project leaders, who say “X is going to be the goal of 21.05”, who is actually going to put in their time?

What happens is whatever the individuals contributing to the project want to spend their time on plus what a small number of companies around the Nix ecosystem (e.g. Tweag and NumTide) contribute based on their (customer’s) needs.

I am also not convinced that Debian is a good example. We are doing better on a lot of metrics. More packages, more fresh packages, a far lower bar for contribution, quicker adoption of new technology, a single coherent repository rather than many disjoint repositories, etc.

At the risk of becoming to repetitive. I think currently our biggest problem is that we have a lot of packages combined with many inactive maintainers. A common pattern is that new people show up, they add the 5-10 packages that they need and then they disappear. The maintenance is then left to the people who stick around.

ckampka · November 20, 2020, 3:58pm

All of that is nice to have, but only if you can manage the workload that comes with it.
The Nix* community as it stands can not.

That is a pattern that is common for a lot of distributions and unavoidable for projects where people are contributing based on their intrinsic motivations alone. All volunteer-driven distributions have that issue, but most decide to deal with it before it becomes a problem, usually by moving those packages to an unmaintained space so they do not become a burden on others. The fact that Nix* chooses to address this the way it currently is is not a problem, its a choice.

I must admin, I sympathize with that a lot. On average, I wait about a month or more to get a review for a simple version bump reviewed, and that is with multi-channel begging for it. That gets you frustrated very quickly. Though I am still listed as a maintainer on a couple of packages, I cannot even in good conscience call those packages “maintained” because I cannot tell if a fix that I push in June will make the cut for the release in September. That basically already stops me from taking on anything else except from drive-by patches that I don’t want to maintain in overlays or that scratch some particular itch.
Which brings me back to the beginning of the discussion: Unless someone steps up and faces the blowback of cleaning up nixpkgs and get it into a workable state again, this whole situation will not improve on community consensus, at least I can’t imagine how it would.

timokau · November 20, 2020, 9:13pm

ckampka:

danieldk:

A common pattern is that new people show up, they add the 5-10 packages that they need and then they disappear. The maintenance is then left to the people who stick around.

I must admin, I sympathize with that a lot. On average, I wait about a month or more to get a review for a simple version bump reviewed, and that is with multi-channel begging for it. That gets you frustrated very quickly. Though I am still listed as a maintainer on a couple of packages, I cannot even in good conscience call those packages “maintained” because I cannot tell if a fix that I push in June will make the cut for the release in September. That basically already stops me from taking on anything else except from drive-by patches that I don’t want to maintain in overlays or that scratch some particular itch.
Which brings me back to the beginning of the discussion: Unless someone steps up and faces the blowback of cleaning up nixpkgs and get it into a workable state again, this whole situation will not improve on community consensus, at least I can’t imagine how it would.

Check out marvin. Its not a silver bullet of course, but it might help. It puts you in an active position: Currently the oldest unreviewed marvin PR is one month old. If you are frustrated by the lack of reviews, you can put on your reviewer pants and clear the queue yourself. That could be done by a single motivated person today.

I hope you keep upstreaming your improvements.

ckampka · November 20, 2020, 11:41pm

Sorry, but I don’t see how it addresses any of the problems discussed in this thread.
To be clear, the fact that reviews take ages to get to is not the problem, it’s the symptom.
From what I understand of what the bot does, it will likely make matters worse, because
it’s main function is to annoy people and to hug attention to opt-in PRs that would otherwise
be available on a fair basis. So thank you, but it does not really look attractive to me.

danieldk · November 21, 2020, 9:29am

I am not sure how appointing project leaders is going to help with this. You can set a goal “all open PRs should be triaged and reviewed for 21.05”, but if you do not have the manpower it’s not going to happen.

There have been proposals with relatively wide support that could reduce the stale PR problem by empowering maintainers, such as the RFC that proposed a merge bot that allows maintainers to merge PRs against their packages. The RFC submitter did not have the time to bring the RFC to completion. However, if someone could put in the time to revise the RFC, address the comments, and implement such a bot, that would result (IMO) in a large improvement in the nixpkgs workflow. It would also solve the frustration that you describe – that it is frustrating to be a maintainer if PRs of packages that you maintain never get merged.

Any way, I am going to stop here. Because we have drifted far of the original topic, plus it might more other people, since this discussion comes up very regularly .

ckampka · November 21, 2020, 9:42am

I am not sure if we are drifting, because this RFC essentially brings us full circle, just by putting a robot in between. It will enable people to push their own changes through without having to address controversy or discussions. But yeah, lets stop this here

timokau · November 21, 2020, 2:47pm

Coming back to topic: I think it would have been better to make a stronger attempt to sort this out privately or in a smaller circle before escalating the issue. Clearly nobody had bad intentions here. “Misuse of commit permissions” is a serious accusation, and I can only imagine how demotivating that must be. I have no strong opinion on the technical side, but I support @talyz in that sense.

Praise in public, criticize in private. If you want to discuss systematic issues, like self-merging, that can of course be discussed in public. But I suggest to do that with as little finger pointing as possible.

raboof · November 22, 2020, 9:25am

Ah, I didn’t realize the keepassx default.nix and community.nix have different maintainers - sorry, my bad.

Does marking things broken kind of achieve that?

ckampka · November 23, 2020, 2:55pm

Not really. It is better in a way that broken packages are not easily installable, so no-one has to really keep an eye out for security issues etc. but I feel like that is not happening for unmaintained / semi-actively maintained packages anyways I feel.
However, broken packages still impose workload on non-primary maintainers, eg. when work is done across packages, like issue #103997 or worse, when there are leaf packages or tests that depend on broken packages and will light up on hydra or equivalent.
The thing is, marking a package as broken does not impose any work on the person who does it, eg. you can mark a library as broken and not notice or make you care about which packages down the line will be affected.
When removing such a package completely, the evaluation of the nixpkgs tree should more often than not fail if something depends on that package, which should reduce friction for later issues.

jonringer · November 23, 2020, 4:31pm

This is off topic, but personally when I see a package with no maintainers, I take that as a, “no one cares about me”.

If i do some research, and I find that it’s only been a target of automatic or treewide changes for a while, I’ll usually open a PR to have it removed. I’ll cc everyone who has touched it over the past year or two. If no one responds, then it will most likely not be missed.

Examples:

EDIT:
It’s not like I go around looking for packages to murder. Generally these begin failing due to some other dependency being updated. And then I make the decision to fix it or just get rid of it.

nixinator · November 23, 2020, 5:53pm

Lets hope packages that ‘no one cares about’ are not made in Nebraska

This thread show me that nixpkgs need paid full times administrator/gatekeepers/maintainers because it’s a victim of it’s both it’s size and it’s success.

I feel a pateron coming on.

Then again full time paid maintainers will need to be thick skinned to soak up the flack i’ve seen in this thread…

systemtopple

jonringer · November 23, 2020, 6:59pm

Nixpkgs makes querying this pretty easy. We would see ofborg failures if I removed something that others were dependent on.

timokau · November 23, 2020, 7:14pm

Related discussion: We need more defined guidelines for package inclusion - #22 by timokau

The whole thread is somewhat related, but the linked post is the start of the maintainership focused discussion. I tried to avoid linking to my own post, but that seems to be the one where the conversation shifts.