[Nix-dev] On nixpkgs and reasonable code size

[Patrick Callahan]

Would you say that this is somewhat comparable to 'contrib' repos in
general? I would hope nixpkgs could still manage better quality control and
integration than Arch users have with AUR, which is kind of hacky.

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?

On Sun, Feb 21, 2016, 9:24 AM zimbatm <zimbatm at zimbatm.com> wrote:

> Thanks,
>
> what I had in mind is a model similar to Arch Linux. I would like to make
> some definitions first:
>
> committer: person who has commit access to nixpkgs
> maintainer: person who is listed in a given package's meta.maintainers
> attribute
>
> There is a core set of packages that all work together and don't draw
> dependencies from the outside. Those are supported by the committers
> uniformly and the committers are responsible for them to work before
> merging changes. It would include the kernel, some libraries, window
> managers, apps, services, and utils, ..., and associated modules (more on
> the size later). nixos-unstable would only advance if all these packages
> compile on all the platforms. Any security issue on these packages would
> have to be dealt with swiftly, and back-ported as necessary.
>
> Then there are the community-supported packages who can depend on core or
> on community packages. Those are supported by the package's maintainers.
> It's the responsibility of the maintainer to make sure that they work
> properly, are kept up2date and to reply to issues related to them. We would
> still support compilation on hydra but it wouldn't block the advance of
> nixos-unstable. As a committer, any PR submitted to a package by their
> maintainers could be merged directly. And issues for community packages
> would be labelled as such. We could also set a policy that if the
> maintainer doesn't respond to issues after a while maintainership would be
> passed-on or the package removed.
>
> Obviously there is a tension to include everything into the core but it
> should be in function of how much time each committer wants to dedicate
> maintaining nixpkgs vs how much time each packages takes in maintenance, to
> keep the quality high.
> It's the same thing in every other distros, the core usually defines
> things that all the packages depend on. Some times a group of persons
> maintains a collection of packages outside of the core because maybe they
> really like KDE and want the bleeding-edge. If we want to avoid the politic
> we can always copy the set from another distro += nix-specific packages.
>
> Basically we currently have 900+ issues and 300+ PRs on nixpkgs and I was
> wondering how to tackle that. I believe that by splitting the
> responsibilities like that it would make things much more manageable and
> straight-forward. We can accept any new package in community/ provided that
> the person accepts their maintainer role and focus on the core packages to
> make sure they are in good shape.
>
> Cheers,
> z
>
> On Sun, 21 Feb 2016 at 14:58 Vladimír Čunát <vcunat at gmail.com> wrote:
>
>> On 02/21/2016 03:17 PM, zimbatm wrote:
>> > tl,td; I think that we should split nixpkgs/pkgs in two
>>
>> OK, let's discuss.
>> TL;DR: I quite don't get where to draw the line, and what the
>> relationship of the two sets would be.
>>
>> > nixpkgs is getting pretty huge. There is so much surface, [...]
>> >
>> > We have a list of officially-supported packages (the ones built by
>> > hydra). As a user, when installing a package it's not always clear if
>> > the package is supported or not.
>> > As a nixpkgs maintainer it is also unclear what priority should be given
>> > to each package as the of officially-supported packages is not first
>> > class. For example gettext is used everywhere but not directly part of
>> > release.nix
>>
>> I think most packages actually are built on Hydra, and we encourage new
>> ones to set meta.platforms, as otherwise the state tends to rot. (Of
>> course, only a limited set of configurations and platforms is built.)
>>
>> Importance of a package seems a rather subjective matter. Still, it
>> shouldn't be hard to distinguish a set of packages that happen to be
>> present in a large fraction of build-time closures. (That's close to
>> "the" set of mass-rebuild packages with some additional ones, e.g.
>> xorg-server.)
>>
>> Assuming we did decide on what package to put where, what then? Do you
>> mean that support for the less important part would be allowed to lag
>> behind? E.g. heavy-impact changes would only be well-tested on the more
>> important part before merging, and the community might take care of the
>> rest later without blocking channels etc.?
>>
>> --Vladimir
>>
>>
>> _______________________________________________
> 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/20160221/35d69bcf/attachment-0001.html