4 ms·

I am sorry that you had that experience! Broken as in cannot be installed should not happen too often. PRs are built in CI and failing builds on Tier 1 should

I am sorry that you had that experience! Broken as in cannot be installed should not happen too often. PRs are built in CI and failing builds on Tier 1 should be a reason to reject PRs. Hydra currently lists ~4700 out of ~91000 packages failing to build on master. However, most of these are on AArch64 or Darwin.

l0b0 6y ago
The worst was finding that a package I absolutely rely on (I can't remember which one, unfortunately) had been reported as broken something like two weeks earlier, and hadn't yet been fixed. I hope something changes there, even if it means cutting 80% of the packages out of the official repo. Nix is too good an idea to have a broken flagship distro.
- danieldk 6y ago
  I hope something changes there, For stable releases, there is an RFC [1] that proposes to push back the .03 releases to .05 and the .09 releases to .11. This will align the release cycle of NixOS after that of Ubuntu and Fedora. Hopefully, this will lessen the load on testing/fixing high-profile package sets (systemd, GNOME, KDE) and as a consequence leave more time/manpower fixing the longer tail. even if it means cutting 80% of the packages out of the official repo There are different opinions on that. Some contributors believe in a large, single monorepo, while others think nixpkgs is too large. Personally, I have moved from the first group to the second. There are many packages with probably only a handful of users, but they clog up the PR stream. Even worse, many of those packages do not have active maintainers, so they end up being maintained by people who are long-term nixpkgs maintainers/committers (and typically have a high maintenance load anyway). It's kind of interesting that nixpkgs grew so large, because it's one of the distributions that makes it the easiest to add third-party package sets. I guess it's because the bar for contributing a derivation is low (you basically open a PR and wait until somebody merges it) and because committers rarely reject packages for being to much of a fringe package. [1] https://github.com/NixOS/rfcs/pull/80 https://github.com/NixOS/rfcs/pull/80
  - l0b0 6y ago
    Thank you for the detailed response. I wonder if the Arch User Repository approach of relegating anything not guaranteed in any way to a separate repo, with some well-understood promotion/demotion process related to how many active maintainers it has, how often/how long the build is broken, etc.

l0b0 6y ago

The worst was finding that a package I absolutely rely on (I can't remember which one, unfortunately) had been reported as broken something like two weeks earlier, and hadn't yet been fixed. I hope something changes there, even if it means cutting 80% of the packages out of the official repo. Nix is too good an idea to have a broken flagship distro.

danieldk 6y ago
I hope something changes there, For stable releases, there is an RFC [1] that proposes to push back the .03 releases to .05 and the .09 releases to .11. This will align the release cycle of NixOS after that of Ubuntu and Fedora. Hopefully, this will lessen the load on testing/fixing high-profile package sets (systemd, GNOME, KDE) and as a consequence leave more time/manpower fixing the longer tail. even if it means cutting 80% of the packages out of the official repo There are different opinions on that. Some contributors believe in a large, single monorepo, while others think nixpkgs is too large. Personally, I have moved from the first group to the second. There are many packages with probably only a handful of users, but they clog up the PR stream. Even worse, many of those packages do not have active maintainers, so they end up being maintained by people who are long-term nixpkgs maintainers/committers (and typically have a high maintenance load anyway). It's kind of interesting that nixpkgs grew so large, because it's one of the distributions that makes it the easiest to add third-party package sets. I guess it's because the bar for contributing a derivation is low (you basically open a PR and wait until somebody merges it) and because committers rarely reject packages for being to much of a fringe package. [1] https://github.com/NixOS/rfcs/pull/80 https://github.com/NixOS/rfcs/pull/80
- l0b0 6y ago
  Thank you for the detailed response. I wonder if the Arch User Repository approach of relegating anything not guaranteed in any way to a separate repo, with some well-understood promotion/demotion process related to how many active maintainers it has, how often/how long the build is broken, etc.