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 <[email protected]> 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 [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
