[Nix-dev] Commit access

[Herwig Hochleitner]

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160229/de5c8941/attachment.html