[Nix-dev] Commit access

[Thomas Tuegel]

On Mon, Feb 29, 2016 at 8:15 AM, Matthias Beyer <mail at 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