Before nix made me dust off my curlies and semicolons again, I have been active in the clojure community. This is relevant to the discussion, because in clojure, we have pretty much the exact opposite contribution policy from nix: Every single contributed patch has to go by Rich Hickey, after being vetted by reviewers. There are no github pull requests, instead they have a jira workflow in place: http://dev.clojure.org/display/community/JIRA+workflow . While this is fine for a project with such a tight focus, it comes with its own set of problems. Of course, this is also unfeasible for the massive scope of nixos, however, it certainly improves the average quality of contributions that go into clojure and there are lessons to be learned about valuing the time of maintainers and optimizing for their experience.
Personally, even though I now know enough about nixos to be dangerous and effectively co-maintain a couple of packages, I have conciously held off asking for commit access, for various reasons: 1. It's a big responsibility and for now, I think making my PRs as easily digestable as possible yields more net benefit than taking it on 2. Looking at the PR queue, I continue to be bewildered at all the different packages, I have never even heard about. How could I do quality control on them? 3. It would lead to massive cpu exhaustion on my desktop ;-) As to the the topic: I think commit access status might be a bit of a red herring: I can get stuff that I care about into nixos and I can review and test build stuff that I care about. No problem. I don't think adding many contributors needs to hurt the community and it fact I remember it as underscoring the accessibility and friendliness in the community. What does concern me slightly, is the number of merge commits, that I see in master. Those are usually created by just pressing the merge button. When actually reviewing stuff, people tend to locally rebase/apply, test to various stages, and then push. In github, this is visible by "commited with" commits. So if there is a problem with "loose cannons" (maybe maintainers can speak to that), this could be solved by restricting access to master, or by creating multiple upstream branches for various stages of review like "looks good, press merge", "merged locally, nixpkgs evaluates, configurePhase doesn't crash", "built and tested in vm with package *installed*", "tested referrers" and require maintainers to only push to those branches when conditions are met. So, @eelco and the other core maintainers: First of all: A big thank you for your work and for keeping that "all in a day's work" attitude alive. How could we, as a community of contributors and maintainers to nixos, collaborate to save time for you, and time on hydra?
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
