One of the things that really drew me towards the nix community was the lack of gate keeping.
The only real [non-technical] barrier is creating a github account, which is largely ubiquitous anyway.
One of the things that really drew me towards the nix community was the lack of gate keeping.
The only real [non-technical] barrier is creating a github account, which is largely ubiquitous anyway.
Maybe the mostly-organic volunteer-based nixpkgs process doesnāt scale with the ease of github contributions.
ā¦ and a lot of small, easy-to-agree-to-try process improvement are made more expensive by the fact 1) GitHub tracking lacks what is table stakes in dedicated issue tracking, and 2) external tools need to integrate with proprietary-implementation-only, semi-transparently-rate-limited, sometimes-breaking (without documenting the changes) APIs.
This sounds like Ā«making easy things very easy, and medium things hardĀ», and the problem of Nix* processes not scaling is partially caused by the problem of GitHub UX model not scaling to some of Nixpkgs parameters.
Wow that is cool!
For me as a casual contributor (15 PRās merged, 10 abandoned, 6 still open, 1 draft - mostly simple stuff) github seems to work really well. Indeed there are many interesting ideas for improved tooling, but Iām not sure switching to another tracker would really make so much of a difference.
We do this in another project Iām involved in, and TBQH I think itās rather tedious and not really worth it: it adds work (deciding what belongs where, which can be hard) and Iām not sure it has a benefit. Many āpotential bugsā are not high-priority or actionable, so Iām not convinced you actually achieve more ācleanlinessā this way.
Such a barrier would make me very sad - the open model is one of the main things that attracted me to nix.
There are some great ideas for useful tooling here. Iāll resist adding my own until I actually have time to help make them happen, though
Please, letās not do this. This does not add to a qualitative discussion.
Casual contributors do not feel the pain of maintainers, of course. The problem is that it does not scale for the community at large, or maintainers - and thatās my point. Fire-and-forget PRs are not the problem here.
This whole discussion seems predicated on the assumption that the stats are bad. Has anyone compared them to a comparable project with only about 1000 maintainers?
If anything, the stats tell me our tooling is comparatively amazing. We are getting more done with less people than anyone else.
Iām basing this mostly on comparing us with the AUR which Repololgy says has 9000 maintainers.
Echoing what @zimbatm said, I feel like we need better tools to match issues and PRs to interested parties in a more dynamic / casual manner.
Sometimes, I have some spare time, so I think, āmaybe Iāll take a look at some nixpkgs issues/PRsā. I sit down, open up the nixpkgs issues or PRs page on github, and start reading the titles. There are over 4000 open issues / 2000 open PRs, so I know there are plenty that I can contribute to in there somewhere. However, after scanning the first 10 or so pages, Iāve seen a lot of things I am not interested in or know nothing about (Sometimes I run into a massive block of automated issues or PRs created by a bot).
Sure, I could try to review a lot of these things, but if I could find the issues/PRs that:
then I feel like a) my attention is more likely to help the issue/PR and b) Iām more likely to benefit. After a few pages of items which arenāt interesting to me, I usually give up. As a result, my main way of finding issues and PRs at the moment is to wait until I have a problem or want something packaged, then check if there are any related issues or PRs. An then once the issue is fixed, I forget about it, whereas Iād often be happy to look at similar issues in the future.
In an ideal world, I would like to be able to āmatch withā issues/PRs which interest me in two ways:
Things I want to filter/match:
I realise that this is a complex problem. Some ideas for things (of varying difficulty) that might help:
NOT something
in your query to exclude certain strings: presumably there are other things that might help narrow it down to interesting items). Can you subscribe to a search query on GitHub? I donāt think you can, but it would be really helpful if you could.If theyāre possible, I think some of these things would be really helpful for beginners or casual contributors. The ability to just subscribe to a package or topic wouldnāt be a big commitment (you can always unsubscribe, and you donāt feel like you have to respond to every issue/PR), and would help to get the right eyes looking at the right issues/PRs.
For certain languages, ofborg will add a label related to the programming language. This isnāt foolproof as it will just check the directory and see if corresponds with a known language, so applications packaged outside of the directory donāt get labeled.
This also applies to committers as well, we are not interested-in all of the PRs we review, but if itās important enough for someone to take the time to package it, then itās important to them.
Before the last release I really wished there was a way to list all the outdated packages that Iām using so that I can help update them before the freeze.
You can go to Projects list - Repology and find the package.
This has two major shortcomings though:
related tools:
src
EDIT:
I remembered another feature of repology, which is looking yourself up as a maintainer, and then you can navigate to out-of-date packages you maintain. This of course, requires you to be a maintainer for the given package though.
Thanks for the reply.
I did use repology that way before the last freeze and I did update a couple of them. I donāt know if nix-update was a thing then but I definitely use it all the time.
If there was a tool that would go over all the packages that I use and publish those somewhere, I would be more than fine with it. It could then be used for all sorts of things; package popularity, notify of security issues, and let me know when a package that I use has an issue.
I was kinda referencing that comment from @zimbatm.
I too wouldnāt mind receiving notifications that one of the many packages I use needs a review or if itās auto-update PR thing is blocked.
Iām not only interested in the packages I use but I would probably prioritize them.
Something else that came to my mind- how would it be if there is a bot that does this-
check if PR is in format- [channel] <string>: <date or ver or num> -> <date or ver or num>
check if exactly two lines have been changed, ver and hash.
Version should be such that it exists on GitHub master repo, not a fork (since GitHub allows you to refer to a fork with masters url, a potential security vulnerability).
if so , launch ofborg and run <executable> -- help
.
Auto-commit or label (ready for commit).
What does this add over r-ryantm? Very little right now. I went fo the GitHub pulls and maybe 96% such are from r-ryantm. The remaining 4% comes from the fact that repology version is not latest (I think thats what ryantm told me).
But there are obviously times and packages where repology is not at latest version, Iād argue that r-ryantm is not the latest version but aur latest versio.
Also a quick turnaround might also make contributors more likely to submit, which imho is a bigger factor, probably why AUR succeeds at usually being the fastest.
Itās possible to even extend this later based on how successful this is, in safe ways. E.g. only changing buildinputs
or nativebuildinputs
sounds harmless. Same for probably cargohash.
I can code this if this proposal makes sense.
That might or might not be the case.
But either GitHub has had some platform issues in the last 24 hours, or nixpkgs now has so many issues and PRs that searching them does not work anymore
Example: I always get a unicorn timeout at Issues Ā· NixOS/nixpkgs Ā· GitHub
Edit: FYI, I created a support topic at GitHubās forum about that community Ā· Discussions Ā· GitHub
The auto-merge would likely be controversial, related [RFC 0050] Merge bot for maintainers by FRidh Ā· Pull Request #50 Ā· NixOS/rfcs Ā· GitHub. Iām not sure how useful the labeling is, as you yourself said the majority of such trivial PRs are bot PRs anyway. One downside would be that prioritizing such a label would create perverse incentives, making people try to please the labeling algorithm and avoiding refactorings.
As @doronbehar mentioned, I am working on a bot that is supposed to help with some of the issues covered here. In particular the discoverability of actionable PRs and the distribution of the review & triage effort. Its still in development, but already running on nixpkgs and ready for testing.
More info here.
i made a start in GitHub - milahu/nixpkgs-watcher: notifications for my favorite apps
spoiler: no code yet, only ideas
ping @Thra11
lets collaborate : )