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 > > -- > Mit freundlichen Grüßen, > Kind regards, > Matthias Beyer > > Proudly sent with mutt. > Happily signed with gnupg. -- Mit freundlichen Grüßen, Kind regards, Matthias Beyer Proudly sent with mutt. Happily signed with gnupg.
signature.asc
Description: PGP signature
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
