New Merge Policy for an always-green hydra

[jonringer]

@kevincox

I don’t think merging the break to master and waiting for all of the maintainers of dependant packages to fix it is the best approach here. I think the better approach is to merge to a staging branch, then get the maintainers to submit fixes either to master (if the change is forwards-compatible) or to the staging branch.

I would much rather have a master branch that is slightly broken than have many long lived PRs that may overlap in efforts. Nixpkgs is already notorious for PR staleness, I would rather have more ways to get stuff merged in quickly, than try to maintain a fragile house of cards.

Also, people usually discover issues because it’s in master, not because it’s in a PR. This might be remedied through notifications, but that 's still an “opt-in” subscriber model, where-as master is more likely to uncover broken packages.

@kevincox

For example people contributing packages and fixed would like to see their changes go out fast, it is quite annoying when your change gets blocked for a week or so.

Most of these situations are from PRs not in a state to be merged, some get forgotten, and rarely some just become massive and those take more time, energy, or resources than a committer is willing/able to dedicate (some of the pytorch PRs, acme restucture and others)

@kevincox

Of course this still doesn’t help with unresponsive maintainers, but at some point I guess we need to call it and mark the unmaintained packages broken

This is a huge problem for a lot of leaf packages. For the python packages, I usually will fix packages if I see that they are broken in another review, but most of the cases are that the maintainer hasn’t been active for years.

At least for me, marking something broken is that it’s non-trivial to get the package back into a building state. Personally, I think this distinction is almost a “marked for removal”, unless someone want to take up maintainer ship. For python packages, I’ve begun removing packages that have been marked broken for more than a release (e.g. python3Packages.zope_i18n: remove due to prolonged breakage by jonringer · Pull Request #95351 · NixOS/nixpkgs · GitHub)

@kevincox

I agree. I think with some decent tooling for at least notifications, and ideally also for marking as broken this would be a good solution.

I absolutely agree, and it’s been brought up many times. We should probably come up with 1 or 2 scenarios that people are likely to adopt, and implement it.

Previous discussions:

RSS feed for "newly failing builds" from Hydra

It’s been mentioned a few times that people would like alternative ways to get notified about their packages being broken. I was just curious about extending hydra to also providing an rss feed for “newly broken packages”, this would allow for people to subscribe to packages that they care about. I’m just curious if this is something that the greater community would care for.

• many others, just too lazy to find them all.