[Nix-dev] On nixpkgs and reasonable code size

[Mathnerd314]

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 <zimbatm at zimbatm.com> 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 <Adev at adev.name> 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 listnix-dev at lists.science.uu.nlhttp://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>>
>> _______________________________________________
>> nix-dev mailing list
>> nix-dev at lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160222/e84c6e44/attachment.html