I wanted to ask your opinion about the possibility to “flag” a package on Nixpkgs out of date. At the moment, an issue at GitHub has to be opened, a lot of information has to be filled in, and even the current version number and the desired new version number have to be stated.
From the perspective of a user, this is a lot of unnecessary boilerplate. It would be preferable to have a data base accessible with all available packages (on Nixpkgs master I guess), and a button “flag this package out of date”. Like this, packages cannot be flagged twice. The package maintainer(s) have to check the new version of the package anyways, and correspondingly update the Nix expression.
I don’t get the point. If they are not maintained, who updates the packages when they are reported out of date via GitHub Issues? What would be the difference when packages are flagged out of date in some other way?
I agree it would be neat if we had some page that can collect most of the information asked for in the issue template and pre-filled it. That looks possible, but not trivial .
While maybe technically accurate in the sense of listed maintainers (I haven’t done a survey), I think this characterization might be a bit misleading. Many packages have listed maintainers, and I believe we’ve stopped accepting new packages that don’t have a listed maintainers. On top of that, there are many people with commit access that maintain lots of packages without being listed as a maintainer for it. During releases, we do Zero Hydra Failures where the community tries to fix as many packages as they can.
Your bot also does a great job at updating a lot of packages, but the reality is that we have a lot of “drive-by packagers” who see a package that is missing, make a PR to check it in, and then immediately abandon it. That is not really a profound problem, because none of these packages are critical.
I feel a bit offended by this statement. I’m trying over and over to move things into the right direction with my own time and I have a very poor success record.
You are referring to a completely different aspect. The present issue is about external tooling, not about altering the foundations of nixpkgs. The issue you’re trying to solve might be better tackled as an RFC. Trying to “shoot from the hip” with a PR for such things is generally bound to fail (see e.g. USE flags).
I still feel offended. Not directly by you, but systemically by how things are.
From the viewpoint of the community as an (hypothetical) independent actor, there is no point in achieving “cheap” consensus about (a general idea of) resource scarcity and at the same time not achieving “effective” consensus about making practical and efficient use of the available ones.
It’s gross.
We can leave it here, since it’s off topic, as you correctly noted.
One of my stretch goals was to have you enter your maintainer name, and it would show you which of “your” packages are now failing, when they began failing, etc. From a UX standpoint, I’m still not certain how this should work, because of how many branches a user may care about (e.g. master, staging, staging-next, release-XXX). Also, people may only be a maintainer on a given branch…
Maybe I could have some repology / github integration which would also determine which are out-of-date as well.
Would be nice to bring more value in declaring yourself as a “maintainer” in nixpkgs.
@blaggacao Thanks for pointing me towards the github client, it seems a rather useful tool!
@jtojnar The repology notification tool is definitely a must have for maintainers! I will set this up for the one package I am maintaining at the moment :), there will hopefully be more.
And yes, it would also be great to have an “update request review” tool.
Nevertheless, I think the points are all made from the maintainers point of view. For users, maybe a clever GitHub Update Request Issue template would solve the additional boilerplate when reporting outdated packages. In the end, the act of “flagging” a package out of date feels more natural to me though.
and then create a PR with the bump. It is more involved, but less involved than finding where the nix expression lives, finding the latest version, update version, calculate new sha, building it, making a commit, then pushing to a fork.
For patch bumps, the above code is probably sufficient. For larger changes, there will some nix knowledge needed.
I agree this would be very useful. I think it would also be useful if you could add packages to this list of “your” packages manually: this way you could track packages that you care about (and might want to help get unstuck) even if you’re not ready to declare yourself maintainer.
.