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

[Marc Weber]

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.

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)

  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.

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

- 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 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.

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.

Marc Weber