[Nix-dev] On nixpkgs and reasonable code size

[zimbatm]

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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160221/219c3660/attachment-0001.html