notifications for my favorite apps
generate more user-involvement in nixpkgs issues and PRs
github has the "watch repo" feature, where i can select "all activity". if i do this for nixpkgs, this will flood my inbox with 100s of mails every day
i want something similar, but i want notifications *only* for my favorite apps. for example, i use the kde plasma desktop, so i want notifications for issues and PRs dealing with this app
existing solution: somepackage.meta.maintainers. but i dont want to be a "maintainer", i just want to "watch" my favorite apps
get a feed of nixpkgs notifications, but not to my email inbox. maybe matrix chat protocol? the whole feed should be sent to my machine, so i can do the filtering offline
maintain a list of my favorite apps. installed apps, github stars (useful for packages that are not-yet in nixpkgs), ... this is used to filter the feed from nixpkgs
map issues to packages. maybe: parse package from issue title. maybe: have a bot to auto-generate labels like pkgs.plasma-desktop (if the auto-generated label is wrong, aka false positive, it can be manually fixed by "someone")
too many notifications. then let me "filter by random", similar to chatroulette ... nixpkgs-roulette?
something browser-based, because github is in the browser
or a fork of the github-desktop client?
collaborative editing of github PRs. github's PR interface makes this hard, but making patches to PRs should be simple and fun
different than How to 'Watch' only a directory in a GitHub repository? because they watch commits, but not issues or PRs
https://discourse.nixos.org/t/stats-trends-on-github-issues-prs/7936
raboof:
we recently hit 4000 open nixpkgs issues, which made me curious about the trends in those numbers. I wrote a quick script to get them from the API and break them down per month
jonringer:
Ultimately, we just need more people reviewing PRs (not necessarily committers, but it can be frustrating to have a PR polished and no committer to push the button). But the work is largely unrewarding (unless it affects you), and can be very time-intensive.
zimbatm:
It would be great if it was possible to “subscribe” to a package more dynamically. Interest doesn’t map 1:1 with the git history. Sometimes I package a thing because I want to go in a direction, then loose interest.
Ekleog:
feed per package so that people would be able to subscribe to the ones of interest to them
renatoGarcia:
if i had sooner received some message or read in someplace that my reviews would be useful even i being a newcomer, i would had started to post reviews to my packages earlier.
musicmatze:
github does not scale for nixpkgs
Thra11:
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
[...]
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.
https://discourse.nixos.org/t/triage-stale-issues-and-prs-automatically/1809
arianvp:
Currently nixpkgs has thousands of stale issues and PRs
https://discourse.nixos.org/t/suggestion-to-help-maintainers-with-nixpkgs-prs-bloat/4794
[quote="doronbehar, post:5, topic:4794, full:true"] I’m not implying that not enough PRs are merged. I’m implying that there are too many and it makes it unfeasable to distinguish between those worth attention and those not.
doronbehar:
I don’t see why should we implement this our selves from scratch within ofborg (NixOS/ofborg#216). From a Google search and a GitHub’s Marketplace search, I’ve found these alternatives which might interest us:
- https://github.com/facelessuser/label-bot - not a one click install GitHub App, but I think you’ll like this feature.
- https://github.com/marketplace/trafico-pull-request-labeler - Seems to implement most of what we want automatically, besides letting non committers change labels with comments as in facelessuser/label-bot#lgtm.
- https://github.com/marketplace/actions/label-approved-pull-requests - Implements only a subset of the features we’d like to have but still worth mentioning in this list.
- https://github.com/marketplace/devbots-needs-review - Again, implements only a subset of the features we’d like to have but still worth mentioning as it may be coupled with other bots / actions for completeness.
Also for issues, there are some interesting apps:
- https://github.com/marketplace/issue-label-bot - The most interesting one in this list IMO.
- https://mlbot.net/
- https://github.com/apps/responder
RFC51 added a stale bot, which I think addresses the main actionable issue in the original post
https://discourse.nixos.org/t/is-git-github-the-appropriate-tool-for-us/12474
jonringer:
Nix doesn’t really have a technology issue, it has a people issue. There’s just too few trusted people in this purely volunteer organization to handle the overhead of issues and PRs.
https://discourse.nixos.org/t/the-best-way-to-attract-attention-to-issues-and-pull-requests/1130
https://discourse.nixos.org/t/nixpkgss-current-development-workflow-is-not-sustainable/18741
samuela:
In Nixpkgs, anyone at any time can break any of your packages. Recently, the latest
staging,staging-next, andpython-updatesbranches were merged intomasterresulting in thousands of new commits breaking about half of all packages that I require in my day-to-day job. [...] These changes are made without any substantive form of CI (nixpkgs-review, etc) and oftentimes without even a peer-reviewed PR. [...] How is a package maintainer expected to know when someone else breaks their build? [...] The current system is simply not sustainable for downstream package maintainers, especially considering that these breaking changes come with no prior notice, no migration plan, and no alerting of failures.