[Nix-dev] Commit access

[zimbatm]

IMO the mention bot already does a great job at getting notified without
having to watch the whole repo.
The next thing would be to get a more reliable and fast CI for the PRs.
Right now there are too many false negatives which trains us to ignore the
red. Waiting for hours for something small to be tested also means that
there are going to me more contexts switches and it's draining after a
while. Once we have that we can then consider adding another bot that
controls the merges and only allows to merge when everything is green.


On Mon, 29 Feb 2016 at 22:51 Herwig Hochleitner <hhochleitner at gmail.com>
wrote:

> 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
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160229/07d3ff82/attachment-0001.html