[Nix-dev] Again: Why don't these people have commit access

[Michael Raskin]

>I'm under the impression that none of the proposal inspired by outside
>project seem to fit NixOS, because NixOS is a very different project : it
>is a huge and complex linux distro.
>
>The first consequence is that it is impossible to have expert on each part
>on NixOS, because each tiny part requires a specific expertise. To work on
>python packaging, you have to be a python developer, to work on kde
>packaging, you have to be involved in the kde community, and to work on
>libreoffice packaging you have to be knowledgeable on how libreoffice is
>built (and very patient). I reckon you'll find much people who are

Trust me, you also need a nice build machine for that... 

I didn't become more patient to contribute more to LibreOffice builds; 
I didn't learn more about LibreOffice. I bought a nice Brix, though.

>confident enough to review a change on a specific part on NixOS than you'd
>find in another project.
>
>Secondly, the scope of the project is so huge that checking nothing is
>broken takes forever. I most projects, you expect contributors to run the
>tests and make sure nothing breaks, but in NixOS, that's much harder. We
>make travis timeout, and we do not have enough resources to build a tight
>CI that tests every pull request before merging it.
>
>Finally, even the definition of "broken" is more blurry than in other
>projets. We usually have a few hundreds failing evaluation in hydra, and
>the number is quite stable (much fewer than we used to have before the ZHF
>project, though). Those failures might be linked to unexpected side effects
>of commits, changes in outside world (a tarball has moved) or any kind of
>transient failure. It is not possible, as of now, to declare that nothing
>must break.

Thanks for a nice summary. I am contributing small pieces to NixPkgs for
a long time, and I agree with every point you make.

>I fell that any proposal would have to take those points into account to
>fit NixOS. Sadly, I do not have proposal, except maybe to find a rich
>benefactor and throw a lot of money at hydra.

Hydra @ Home, obviously! Yes, that is why I would like bit-perfect
builds...

I think there is a bit of history that is useful for context: I remember
when we all agreed to lower the expected committment for package 
maintainers so that de-facto maintainers would usually write themselves
in the meta.maintainers attribute.