[Nix-dev] Commit access

[benley at gmail.com]

I would love to see a workflow involving a merge queue, where normally
humans should never push directly to master nor click merge on pull
requests, but instead:

1. developer opens pull request
2. travis runs tests, posts results as usual
3. someone with approval/commit rights comments: "nixbot: OK to merge" or
something to that effect
4. the bot merges or rebases the PR to a staging branch and triggers a test
suite against it
5. If those tests pass, the bot pushes the results to master.

This workflow, in theory, could yield a master branch that always has tests
passing.  The catch is that it would effectively require serializing the
merge queue's test runs, since if master changes during a test then the
results become invalidated.  To address that, there is a project called
Zuul[1] that the Openstack project developed to handle this workflow.  It
manages a gating merge queue, and enables parallelizing of test runs by
strategically combining merges, and will intelligently recombine them to
isolate individual merges that don't pass.  The flow is better described in
their docs than I can do here, and I suggest taking a look:
http://docs.openstack.org/infra/zuul/gating.html The openstack project's
own instance of zuul may also be of interest for the sake of example:
http://status.openstack.org/zuul/

A snippet:

> Many projects practice an informal method of gating where developers with
mainline
> commit access ensure that a test suite runs before merging a change. With
more
> developers, more changes, and more comprehensive test suites, that
process does not
> scale very well, and is not the best use of a developer’s time. Zuul can
help automate this
> process, with a particular emphasis on ensuring large numbers of changes
are tested correctly.

Zuul is generic enough that I believe it could easily be adapted to work
with Nix, and probably also to run tests on Travis. I do believe that using
a commit/merge queue system like this - be it zuul or some equivalent tool
- could make a huge difference in maintaining project sanity as the number
of developers continues to increase.

[1]: http://docs.openstack.org/infra/zuul/

On Mon, Feb 29, 2016 at 2:51 PM 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/f1aa5f14/attachment.html