On 23 Feb 2016 23:08, "Matthias Beyer" <[email protected]> wrote: > > On 21-02-2016 15:28:08, Bjørn Forsman wrote: > > On 21 February 2016 at 15:17, zimbatm <[email protected]> wrote: > > > tl,td; I think that we should split nixpkgs/pkgs in two > > > > Another way to do it is the Linux kernel way. Instead of splitting the > > (git) repository in two (or more) pieces, split _maintenance > > responsibility_ into a hierarchy. This is opposite to the flat > > responsibility model NixOS development use today. > > I completely second this. The problem is IMHO _not_ that the repo gets big > (there are other repos which are way, way bigger than nixpkgs) but the > development model. AFAIK I said that before on this list. The problem is that > everyone who wants to be a contributer gets push access to master. It just > screams at you "I won't scale"!
Splitting isn't needed. Nix is lazy, editors search, github searches. Refactor the current dev process such that this becomes easier to implement: http://rfc.zeromq.org/spec:22 Evidence: http://hintjens.com/blog:93 This is a falsifiable process, it follows the scientific process. What have we got? Something that doesn't work. Fork C4, document it, evolve it. Let others learn from it. I was shot down for suggesting this, I think there were 300 PRs at that stage, only to have quite a few people message me off list saying I can ping them directly to merge quickly. This is an even greater sign of a broken process, it's also the reason why I have pretty much stopped contributing to nixpkgs. Can we: * stop releases and go for a rolling release. * roll stable and unstable into HEAD. * follow eelco's advice: nixpkgs env var supports urls * if you've contributed 1 or more pkgs then you are immediately invited to become a maintainer. * everyday we could hit 0 PRs, there should be this ravenous hoard of maintainers hitting the merge button. * don't like the merged code? Fix it with another PR. Treat the code like a well run wiki (not our wiki... which is now-read-only-not-wiki :-) ) * don't dwell on finding consensus in PRs just merge it and fix mistakes with more PRs. * seek advice from expertise *and* the people your decision affects, as a way to sidestep a hierarchical structure and full consensus. Don't go the way of linux, don't do consensus. * if we can get this process right, our wiki will come alive and surpass Arch. I cross one leg over, raise my arms parallel with the ground and let my neck go loose, then gently turn my palms skywards. Let the shooting begin. /sjm
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
