On Mon, Feb 29, 2016 at 8:15 AM, Matthias Beyer <m...@beyermatthias.de> wrote: > As this discussion seems to happen outside of the mailinglist, I resend this, > so > everyone on the ML knows: > > On 28-02-2016 15:23:48, Matthias Beyer wrote: >> On 24-02-2016 11:43:22, Michael Raskin wrote: >> > I have fixed and ran the vanity counter script. >> > >> > My impression is: if any of the following valued contributors ask >> > @rbvermaa for commit access, they will almost for sure get it; and all >> > of them have reached the level of experience with NixPkgs where many >> > people have asked and received commit rights. >> > >> > Adding 30 members to the NixOS organisation would be nice, hopefully >> > that would help with the PR buildup at least a bit… >> > >> > ... >> > >> > matthiasbeyer >> > >> >> Thanks for proposing me for commit access to nixpkgs, but no thanks. >> >> Do you people really think that giving away commit access to _even more_ >> people >> will solve the mess we call "nixpkgs" today? I consider this insanity! >> >> Giving away commit access to so many people will result in an even greater >> mess >> than we already have! We already have a discussions where several people >> conclude that our development model SUCKS HARD [0] _because_ >> everyone just pushes on master. We are arguing on how to do the development >> process right and there are a lot of good proposals. We just have to start >> it! >> >> So I propose: Please, Eelco, remove everyone from commit access for >> github/nixos/nixpkgs! >> >> This would be the first step. Then we can add maybe two or people, like domen >> and Rob. >> >> Afterwards we should define "topics": >> >> - Haskell (I guess Peter Simons would be the maintainer here) >> - Python >> - Perl >> - Ruby >> - Java >> - Rust >> - all other language packages >> - New packages >> - Package updates >> - ... more? >> >> These sets could even be extracted out of the current nixpkgs tree: >> >> - nixos/modules: >> - config >> - hardware >> - i18n >> - installer >> - misc >> - module-list.nix >> - profiles >> - programs >> - rename.nix >> - security >> - services >> - system >> - tasks >> - testing >> - virtualisation >> - pkgs >> - applications >> - build-support >> - data >> - desktops >> - development >> - games >> - misc >> - os-specific >> - darwin >> - gnu >> - linux >> - windows >> - servers >> - shells >> - stdenv >> - test >> - tools >> - top-level >> >> Of course one person could be maintainer for several subsets of the >> repository, >> though I'd not give away more than three subsets to the same person. >> >> And define maintainers for these sets. >> >> Afterwards, and this is an _important_ step: >> We should create _one repository for each of these topics_. Pull requests >> should >> be filed against these repositories. The maintainers of these repositories >> may >> ask periodically for a pull into the main repository. Something like >> >> - new packages every 5 days >> - package updates every 2 days >> - Haskell packages every 7 days >> - ... etc >> >> All of these PRs should be already known as "build-succeed" ones. >> >> This is a tree-like model like it is used in other distributions and big >> projects like the kernel or git itself. >> >> As I know that we are great in discussing things but not that great in doing >> things, I do not put that much hope in this mail, though I hope that Eelco >> and >> the others will at least not offer push access to these people. >> >> [0]: http://thread.gmane.org/gmane.linux.distributions.nixos/19586
+1 for dividing responsibilities along a tree hierarchy. -1 for doing anything before 31 Mar 2016 or closure-size is merged, whichever happens last. -0.5 for the scorched-earth policy of removing all contributors before dividing the repository. (It would be -1, but as a general rule I _love_ scorched-earth policies.) I've said before that having a hierarchical tree of responsibilities is the best (only?) way to scale-up NixOS development. I don't think we should remove commit access _before_ dividing up the tree, though. Right now, the filesystem tree is a bit of a mess. For example, I would be the natural choice to maintain the KDE 5 tree. If we divide the repository along filesystem lines, the KDE 5 packages would be in my domain, but not the NixOS module. That's a big technical problem, because they usually need to be updated together. (From a non-technical perspective, it's just silly.) I like this idea, though. After the release, and after we have cleaned up the closure-size fallout, I think we should take 1-2 weeks, reorganize the repository sensibly, split it up along some lines and _then_ remove the extraneous contributors from NixOS/nixpkgs. Regards, Tom _______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev