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 _______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
