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