Ok, how about this: We split nixpkgs in nixpkgs-core and nixpkgs-community For any package or service, there need to be at least 3 active maintainers, or it goes out of nixpkgs-core into a nixpkgs-community repo.
Hydra builds nixos from nixpkgs-core, and nixpkgs from both combined. nixpgks-core issues are mostly solved by the maintainers or of course any PR that is good enough. In the nixpkgs-community we implement the http://rfc.zeromq.org/spec:42/C4/ process, meaning that any PR that fulfills all the objective goals gets merged. It worked well for ZeroMQ, and takes the guesswork out of PRs. Tree maintainers only need to evaluate the C4 objectives <http://rfc.zeromq.org/spec:42/C4/#23-patch-requirements> of the PR, and if they are fulfilled, merge. Packages get moved between the two repos as support status changes. That way, we have a small "trust base" for server systems, and a large "community base" for the latest and greatest. NixOS is so flexible that you can mix and match as you wish. On Fri, Jul 22, 2016 at 3:12 PM Kevin Cox <[email protected]> wrote: > On 22/07/16 08:55, Alexey Shmalko wrote: > > This one: https://www.codetriage.com/nixos/nixpkgs > > > > That's it! I have subscribed to get a couple issues a day so hopefully I > can help a bit. This site seems like a nice way to spread the load. > > It's open source too, and I just opened an issue asking them to > implement filters as I'm not really interesting in seeing in-progress > issues. > > https://github.com/codetriage/codetriage/issues/498 > > > _______________________________________________ > 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
