Saying that we need to run nixpkgs-review all the time is, in my
opinion, a mistake. We have to either make that automatic, or not
require it, or it will be forgotten. (Also, we should provide an
interactive script somewhere that just does all the things that the PR
template requires.)
Making it automatic on the developer’s laptop is not reasonable, due to
the mass-rebuilds that can occur, and for which another process would be
required.
But we already have a set of machines that does these mass-rebuilds, and
it has a feature to automatically ping the maintainers of packages that
are newly broken: hydra.
Does anyone remember why the automatic emails have been disabled, and
why they haven’t been reenabled since? There has been one spam incident
once where hydra started to send thousands of emails to everyone, but as
far as I know that was the exception and not the rule, and it brought
more advantages than disadvantages overall – I’m pretty sure just
reenabling it would help a lot to keep nixpkgs not-broken.
Reverting is fine when there is large amount of breakage but in reality it is often not so black and white. Large fraction of breakages I encounter is breakage of a few leaf packages – it is sad that it broke some packages but reverting the breaking change would be actually a change for worse.
The Qt breakage is actually one such example. Before the introduction of wrappers, every Qt package was broken. If people were lucky and had homogenous environment, it worked for them, but I marked several issues as duplicate every week:
The solution Thomas chose was to make the breakage explicit and give maintainers a way to finally fix the long standing issue. We cannot blame him for not having enough time to also fix the world.
I believe this would be a good process if NixOS had a hybrid structure, where nixos-unstable became an actual rolling distro. Which I feel might be strenuous on the structure of a mono-repo (how should that even look like exactly? more branches can turn into more work). I’m not sure how I feel about keeping nixos-unstable in such a primed state and calling it “unstable”.
I do agree that the “one defined moment” of zero hydra failure initiative isn’t working as good, but I believe that is because nixos-unstable moves so fast and your package failing to build has no notification. The people that are aware of these things quickly are using nixos-unstable and tracking development delicately.
I disagree. Automating it would be much nicer, but I don’t think its a requirement. There’s a checkbox. There’s not really an excuse to forget it and accidentally check the box. And if it does happen every once in a while, there’s the revert option. It doesn’t have to work perfectly to be an improvement.
Yes, in that case there’s staging.
I agree that we should have hydra notifications (Re-enable email notifications · Issue #51 · NixOS/infra · GitHub). But those should be a last line of defense. Fixing my packages after they were broken on master is like putting out a fire. It’s stressful for me and annoying for the users. Fixing them with a week’s notice and additional context is much nicer.
I’m not saying we should block indefinitely because of leaf packages, just let it sit for a week. The status quo has been working until know, it will work for a couple more days. Of course there will be special cases, and maybe the QT thing was such a special case (I don’t have much context), but this still applies to most cases.
My suggestion would not require him to fix the world. It clearly defines who has which responsibilities, and where those responsibilities end. The author of a PR has to
make the change
evaluate its impact
notify impacted maintainers
He does not have to fix everything.
I already use nixos-unstable as a rolling distro and I think a lot of people do. I’m not sure what you mean by more strenuous or why more branches would be needed. I don’t think the name is much of an argument
Yes, in that case someone would notice the runtime breakage. They’d then revert bisect the issue, revert the change and ping the author. They can then come up with a build-time test (as was done for the QT change) and ping maintainers.
OT: It’s so nice that one grumpy message from @rkoe, after some rocky start, turned into a real discussion. In a lot of other communities this thread could have become a flame war
First of all: Sorry for the wording – I was quite frustrated, then. I do not want to insult, annoy or displease anyone, and I do not want to devalue others work. Sorry for that.
I really love the technical concepts of NixOS and I’m thankful for the work many people are putting into it. Thanks for that.
The QA-problems nevertheless still exist (and I’ve experienced it again with the recent 20.03 upgrade). I’m really interested in a solution here and am willing to help.
Unfortunately, I did not have time recently to think more about this, but now I’ll soon try to offer a concept for discussion how to solve these issues.
