Flag packages out of date

[raboof]

I don’t think I understand what you’re trying to propose…

[blaggacao]

Oh, ok, so here is another take from a different angle. Hope it makes sense.

Instead of inaugurating a sattelite database for the purpose of managing personal todo lists, I propose to stick with github, which the community by large has already adopted (for the worse or for the better).

This, as opposed to a sattelite data store, can efficiently leverage existing third-party tooling (gh) and intergrate well with existing gh enabled cli (or web ui based) workflows.

I’m aware that this perpetuates lock-in with github. Though I think consolidating workflow requirements (even around that tool), ultimately contributes to lower the switching costs.

[abathur]

@raboof

@jonringer

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

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.

A little oblique, but I’ve mentioned before that letting (encouraging/nudging?) people to indicate that they use or depend on packages might enable some interesting ~distributed levers.

• I think it would need to focus on carrots at first. An example would be notifications when a package you depend on:
  • has been failing on hydra for [reasonable timeframe]
  • is updated (maybe some subset of updates?)
  • is marked/unmarked broken
  • becomes unmaintained or has a maintainer change
• If the carrots do provide value and people bother signing up, it could build up a well of knowledge/experience that can help test changes, identify/develop tests that reflect real-world usage, locate new maintainers, etc.

[blaggacao]

@abathur

~distributed levers

→ I might assume that you refer to network effects?
(and occasionally/unaskedly would introduce that concept to the unbeknownst)

[abathur]

@blaggacao

When you say “distributed levers”, do you mean something different from “network effects” or am I allowed to substitute for my own understanding?

I do mean something different, though I didn’t intend to get deep enough into what is ultimately an aside to clarify how.

I'll tuck it into a details section to minimize disruption

There’s probably network-effecty value bound up in something like this, but it doesn’t strike me as the right focus or emphasis?

I focused the list of carrots on fairly straightforward individual benefits that might incentivize people to add themselves to a list without much concern for how or whether their total benefit scales with the length of the list.

My focus is on whether the project can add value above and beyond the time invested in creating and maintaining the system by building additional tools on top of it. (I mean something beyond just sending everyone an email and hoping a crowdsourced solution falls out.)

Some maintenance tasks are harder than necessary because the people performing them lack knowledge/experience that a package’s users have, with no great way to close the gap.

I called these “~distributed levers” because it’s probably a number of small components that, as a whole, make these lifts easier:

• enable maintainers to indicate acute needs (ex: does this change work)
• enable us to indicate systemic needs (ex: accumulate reports about whether something builds on a platform that isn’t marked supported)
• nudge package users about this need at some sensible place in close proximity to their use of the package (i.e., before/after a build)
• enable package users to collect and return the requested information in a quick low-friction manner that hopefully won’t derail their work with a big context switch
• do something context-appropriate with whatever is collected
  • validate and propagate change test/feedback to the PR
  • validate a test case, generate a report, and write a patch/commit/PR for it
  • notify the maintainer that it’s available
  • …

I suspect experience/familiarity with a package would drive most of the value and that the value added wouldn’t continue scaling much with the number of participants once there are enough to get good, timely answers (and might roll off if low-familiarity users are providing incorrect or low-quality feedback).

[blaggacao]

@abathur

Some maintenance tasks are harder than necessary because the people performing them lack knowledge/experience that a package’s users have, with no great way to close the gap.

Ah thanks! That totally clicked in my brain. Systemically, the issue at hand (in my words) is how to “shorten” or “close” that particular feedback loop.

We have two disparate knowledge domains, even three:

• the ones that produce a particulat piece of software
• the ones that package it for nix (our eternal bottleneck)
• the ones that use it.

In my way of looking at this, producers and consumers are already sufficiently close in open source (thanks to github/etc). If we can eliminate the need for packagers to insert themselves into that (already established) feedback loop, we might have discovered a pathway to a solution.

I might been having a similar impetus while I was redacting this “sister” post:

Geistesblitz: nixpkgs-update to spur flake conversion

I’ll try to be short. Kindly let me know if too short. Problem a lot of packages are regarded by the community as unmaintained. Solution Let’s try to apply a systemic solution to a systemic problem. eg nixpkgs-update starts to replace builtins.fetch* with its flake equivalent (where possible) over time, each package becomes it’s little “mini-flake” after a while we can write a bot who proposes (via PR) those flakes for upstream inclusion replace in-tree implementation with a ref to upstre…

[rjpc]

is this still the best way to find outdated packages? edit: seems to be; sorry for noise.

[dschrempf]

I think so, yes. GitHub/Nixpkgs is the hub for all Nixpkgs issues including outdated packages. I have become used to it, but it may keep possible contributions of new users at bay…