I guess to some degree the possibilities depend on whether packages that “do not work” are failing to build, or build fine but still don’t work correctly.
I’m definitely not “blaming” you hardworking people and the people who spent precious time to comment on my pr but #77734 I didn’t add maintainers to meta and nobody commented. (I’m not blaimin, I’m just saying the practice could be more widespread)
Please see nixos lts discussion
We haven’t made adding a maintainer to modules mandatory. If you had written a package I can assure you that someone would have mentioned this.
your PR is a nixos module, most of those just have the maintainer in the meta section. Also, I’m not sure if modules are as “standardized” as are packages.
It’s crazy right now, I think ive been addressing 20-50 PRs a day, and the count keeps getting higher.
EDIT: addressing means commenting, reviewing, or merging. Not just merging
7 Likes
If the nixos foundation had enough money to employ people to do this, then these might be realities. As it stands, maintaining and curating the packages is done by volunteers who are giving back to a community/ecosystem that they resonate with.
Because the design of nix is so declarative, I think that future tooling could go really far in automating away much of the pain (E.g. minor version bumps, then doing a full build of every affected package and running of tests)
5 Likes
I understand the wish but not how any step towards this would look like that would not automatically be qualified to be in nixpkgs itself.
It seems one can have either of
- very new and perhaps not tested well
- older (since the time of the last proper test)
If there was an approach to get both new and well tested, why should we put that approach on a channel and not directly on nixpkgs (release and master)?
I also don’t see how making more channels than unstable and the stable *-release channels would help anything:
If something gets broken we should fix it on both these channels. How would having a third channel help beyond that?
Futher, my understanding is that changes like the Qt-wrapper changes could not live on some unofficial channel, because they fix fundamental things that e.g. help running Qt apps on non-NixOS. They need to land on the main branches so that peoples’ apps are not broken.
I’m constantly getting broken (and partly very very old) packages
The best ways to counter that are to:
- Become maintainer of those packages that you use and that break often (it is quite easy indeed!)
- Add NixOS tests for those packages you use so that people can easily automatically get notified when they break them.
4 Likes
I’ve started a new full thread with a vision on this dedicated to this topic:
Steps towards even more PR automation
2 Likes
I think his/her point was that it should just work without having to put forward a lot of efforts.
I think his/her point was that it should just work without having to put forward a lot of efforts.
And nh2’s point is that there is no «just works» and these efforts still end up being needed… I guess an implicit point is that the discussion will always end up framed as «how we help contributors to get more things done with less effort» and not «how we provide things for ‘invisible’ users allowing them to stay invisible and content», so becoming a maintainer of something makes one heard more.
2 Likes
There are many packages in nixpkgs that are very domain-specific. E.g., I was happily surprised to see two days ago that the sentencepiece library is already packaged. But given the modest size of the Nix community, the small subset that is interested in natural language processing, and the subset of NLP folks that would use sentence piece tokenization, I wouldn’t be surprised if there are at most a dozen users besides the maintainer. One can get far with automated version bumps and tests. But with this kind of package, you have to expect to maintain it if the maintainer loses interest and the automation fails.
So, besides automation, I think it is also important to focus on how we can help/encourage newcomers to start submitting patches and/or become maintainers. Nix is also a community, not (just) a product that one can expect to always work.
1 Like
I would love to become a maintainer and contribute to the community but would surely need some guidance if not handholding…
Maybe there could be some kind of step by step (video) handbook on the wiki?
Most of the time I can find some info on YT video’s but perhaps that info should be more prominent available right here on the NixOs domain.
Edit: I stand corrected >> Update a package - NixOS Wiki
But then again I had to search for it. Perhaps we should provide a big green button “we need you to become a packager!!”
3 Likes
This discussion is somewhat related:
https://discourse.nixos.org/t/we-need-more-defined-guidelines-for-package-inclusion/
Removing inactive maintainers from the list may make it easier to identify unmaintained packages.
Hydra used to send an email to maintainers when one of the packages they maintain breaks. Unfortunately, this is not the case anymore. A consequence is that since I am on NixOS stable, it is quite likely to not even notice that a package I maintain is broken on nixos-unstable. This makes it harder to be a “good” maintainer and keeping high quality packages.
And contrary to solutions involving more and more tooling, I expect that re-enabling this functionality is easy — nothing to code, only a slight change in Hydra’s configuration.
9 Likes
A simple suggestion: extend the meta.broken field to something that represents the the level of maintenance that this package receives. So we could differentiate between “I make sure this package builds” and “I extensively use this in my day-to-day work and thus test new versions throughly”. This would also help for PR review process: if the package level is just “it compiles”, then I can feel safe to merge it if ofborg says its fine. While if it says that the maintainer does extensive testing, I would just leave it to them (this level of maintenance should also come with some level of availability of course or even require multiple people listed as maintainers).
1 Like
Thanks for pointing to this discussion:
https://discourse.nixos.org/t/we-need-more-defined-guidelines-for-package-inclusion/
I’ve wondered if the Nix ecosystem might be able to leverage the knowledge and activity of its userbase better with fairly simple tools composed thoughtfully?
I wrote several specific examples out initially, but I think it risked obscuring the forest with the trees. It’s not one big idea–just a lot of small ones. Most are about identifying useful knowledge/information in the ecosystem, finding low-friction, privacy-respecting ways to collect/aggregate it, and ensuring it makes its way to where it’s useful (for maintainers, contributors, and users). Some themes are managing user expectation/frustration with transparency; using focused, well-placed nudges to collect information or solicit help, and making a package’s context more readily available to maintainers/contributors.
Some broad categories:
-
Let people using an [at-risk] package know that it’s [at-risk], that the community could use their help making sure it’s in good shape, and give them low-friction ways to give feedback that are context-sensitive to the reason(s) it’s at risk.
I can imagine subtypes/reasons like: low-traffic, no maintainer, inactive/inattentive maintainer (new upstream releases going a while un-addressed), marked as broken, not marked as supporting their platform, recently-updated (with a history of problems after updates), has reported problems, dependency recently updated with a history of breaking after it does, has an outstanding PR/commit that marks it broken or gives it a more restrictive platform…
-
When a package is missing something (tests, tests that exercise a specific dependency, a useful description, a known changelog file, its homepage domain no longer works, etc.), solicit actionable help from people when they use it.
-
Use heuristics to identify common local override patterns (upgrades, downgrades, adding/removing inputs or feature flags, etc.) that imply something about what’s in nixpkgs, ask the user to confirm the hunch, and either pass the information on or nudge them to contribute it.
3 Likes
This approach is exactly to the point: Lowering the threshold for constructive interaction.
I also like your examples in general. The devil lives in the detail though. Having just one of the simplest mechanisms done well would be worth a lot.
I find the possibilities interesting, which makes it easy to go overboard on speculative detail in an effort to convey some sense of the possibility space and all of the ways they could be enhanced/built on.
Some simple examples that are actionable with information available now and without adding some way to collect/aggregate data are:
- Let people know when they build/use a package that has no maintainer. A heavy-handed take can encourage them to become a maintainer. A subtle take could gate the call-to-maintainership with questions like how familiar they are with it, how much they use/like/depend on it, whether they known what a git is…
- The call-to-action may start as a simple message, but a later enhancement might ask if they’re willing with options like: [yes–I know how; give me the path and I and will take care of it], [sure–but walk me through it], [ask me again later], [no]
- Let people know when they build/use a package with no tests.