I think the solution is to automate package updates as much as possible. All the big tech companies can release updates at the push of a button; release management is done by 1 person. The only way to keep up is to also update all the packages in Nixpkgs with 1 button. There's been some work on this, maintainer scripts for GNU / Xorg / Firefox / Chromium / Haskell and the NixPkgs monitor, but it's not very efficient and nothing is actively watching those for updates AFAIK.
Fedora is running their own release monitoring service ( https://release-monitoring.org/), with push notifications to maintainers, and from what I've seen they update Rawhide very quickly (faster than all other distros). But it is still not automated: there can be a week between an upstream release and someone updating the package. I've made a little Ruby script which uses rsync to do version checks, it can pull all versions from gnu.org in 2 seconds: https://github.com/Mathnerd314/nixpkgs/commit/8563a48caf197118bf13757f344baed129593730 But there is no real way to integrate it into NixOS at present, because updates still have to go through a pull request first. If the nixpkgs repo started to consist of package-generating recipes (like cabal2nix and other tools) instead of non-machine-editable Nix expressions, then it might be possible to use it. But this is not happening; instead of Hydra polling Git repositories, which it can do perfectly well, we still have giant semi-automated commits like https://github.com/NixOS/nixpkgs/commit/e713765b53c930fd6ec5e3fbdeb4efe6f14335af which break GitHub and make git clones several hundred MB. What happened to the rule of "Don't keep generated files in version control"? -- Mathnerd314 On Mon, Feb 22, 2016 at 5:55 AM, zimbatm <[email protected]> wrote: > Related to the discussion, apparently even Debian has trouble keeping-up > with security updates: > https://statuscode.ch/2016/02/distribution-packages-considered-insecure/ It's > not a simple problem for sure. > > > On Mon, 22 Feb 2016 at 09:35 Adrien Devresse <[email protected]> wrote: > >> I think the inflow of PRs *is* high wrt. the number of active >> contributors with push access. Certainly too much to keep quality very >> high all the time, but on the other hand, for those less important >> packages it's not a big deal... >> >> >> The way the other distributions solved this issue is by distributing the >> responsabilities. A model where a little minority has to approve / validate >> the merge each package modification can not scale to a huge number of >> packages. >> >> If you look at the Fedora/Debian model, each package maintainer is >> responsible and has full commit access on their packages and only on their >> packages. They do not need any merge, excepted when they stabilize the >> unstable branch. This is quite similar to the way the Linux kernel >> development works in this respect. >> >> >> Adev~~ >> >> >> >> Le 21/02/2016 21:39, Vladimír Čunát a écrit : >> >> On 02/21/2016 09:10 PM, Patrick Callahan wrote: >> >> Does anyone here know what other distros do to engage more >> developers+maintainers? Could we, among other things, organize some kind >> of drive to encourage more systematic contributions? Or is integrating >> all the current PRs too much work already for that to be helpful? >> >> Well, I think the number of contributors grows fast enough since we >> migrated to github:https://www.openhub.net/p/nixos/contributors/summary >> >> I think the inflow of PRs *is* high wrt. the number of active >> contributors with push access. Certainly too much to keep quality very >> high all the time, but on the other hand, for those less important >> packages it's not a big deal... >> >> --Vladimir >> >> >> >> >> >> _______________________________________________ >> nix-dev mailing >> [email protected]http://lists.science.uu.nl/mailman/listinfo/nix-dev >> >> >> _______________________________________________ >> nix-dev mailing list >> [email protected] >> http://lists.science.uu.nl/mailman/listinfo/nix-dev >> > > _______________________________________________ > nix-dev mailing list > [email protected] > http://lists.science.uu.nl/mailman/listinfo/nix-dev > >
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
