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

[Michael Raskin]

>I can only speak for myself:
>In the past the community or some members didn't accept what I did for
>various reasons. That's why I did no longer run for 'commit' access
>since then.

Well, I don't believe in fixing any big issues in NixPkgs (mostly after
the same parallel building story), but keeping a set of the packages
I use non-broken (and not completely out of date) still makes it simpler
to have commit rights.

>A summary with some cases (some time has passed, maybe my memory is no
>longer that accurate - but it should give an idea):
>
>- patches about parallel building got stuck
>  => result: 3 people (Lluís Batlle, me , Peter)
>  tried different implementations. The first patch was not accepted
>  for "no reply is no ok" reason - I didn't get a ok due to minor
>  refactoring of make arguments in builder and because some people 
>  feared about purity (it would have been opt-in)

Yes, "no reply is no OK" was an efficient method to prevent progress
from being made.

>  I messed up hydra that time (due to some -n -j being interpreted 
>  as run as much as possible)
>
>  It was pretty depressing for me because I had need for -j 4
>  and not getting it into nixpkgs made it impossible for me to use
>  hydra.

I must admit I still don't understand the logic behind our status quo...
Why the only way is double opt in without a way to do global opt in
for everything not explicitly marked as a problem. This is also the
reason why we have no idea which of the packages are safe to build in
parallel except for the few packages where someone explicitly tried.

>- patches about cupsd got stuck (due to using versionedDerivation)
>  => fixed printing for me - was later asked on the mailinglist for)

Yes, using versionedDerviation is one of examples of experimenting to 
solve global annoyances. That doesn't work in NixPkgs, I agree.

>- I did mess up python once and did not have time within 5 days or so to
>  fix it - those had to be reverted by Eelco Dolstra
>
>- Work on php-fpm was done twice, by me and by somebody else.
>  My version of php-fpm is more complicated but also very complete
>  because it determines how many php-fpm daemons to start on its own.
>
>- I eventually had pushed the zsh/bash patches (which I guess are
>  partially obsolete now) - they allow users to opt-out and allow
>  modules/the admin to define bash/zsh snippets to be added
>  to a global bashrc/zshrc which gets sourced by ~/.bashrc
>  so that users can opt-out from everything or pieces.
>
>- I would have fixed eigen(2) in krita of calligra much faster
>  => Thus because I have not had "commit" access this had to be debugged
>  twice.

I think "build failure -> works somehow" changes are the ones that can
be committed safely and would benefit from _not being debugged twice.

I try to reduce the amount of such things in PRs, and so I ask everyone
who actually know what they are doing to get commit rights and commit
updates and fixes directly.

>- I have patches pending for apache http and nginx making them more
>  configurable (eg allowing to set the IP to listen to)
>
>.... To sum up: I tend try to apply the 20/80 rule: 20 percent of effort
>should yield 80% of the desired result - which seems not always to be
>good enough.

Another 80/20 rule would be to commit things where there is 80% 
confidence of noone objecting much... I think I try to follow something
like that; if I have less confidence, I sometimes don't even bother to
make it shareable and just add it to my configuration tree.

>Thus in the past I caused both: goodness and badness - thus its fine for
>me that my commits get reviewed.
>
>Thus if PR's don't get accepted I do no longer take it personally -
>changes end up in my topic branches instead.
>
>I treat Nixos to be a very good option to get some jobs done - still
>seeing much room for improvements. Eg there are 3 implementations:
>nixpkgs/a js one and guix. Thus moving towards a "global package
>database more distros could derive package descriptions from"
>is much more important to me than caring too much about policies
>- because I see Nixos to be a tool only to get a job done.

I actually stopped treating NixOS as something that can be used 
policy-free, but NixPkgs are nice (and I hope enough services get moved
from NixOS-only to Nix-Services or something for that to become a second
useful resource).