>The main issue that we still need to decide on is a workflow / access policy >(see e.g. http://git-scm.com/book/ch5-1.html). Input welcome. The two main >alternatives are: > >- A centralised workflow where people commit directly into the master. This is >basically what we did with Subversion. The downside is a lack of review.
The upside is lack of our usual problem where nobody cares to review either positively or negatively. >- A decentralised workflow where people have (public) forks and submit pull >requests to have changes merged into the master. Here the downside is the >overhead of having to do a pull request. > >A hybrid policy is of course also possible. I.e. uncontroversial changes (such >as minor package upgrades in Nixpkgs) can go directly into the master, while If only we knew what constitutes minor upgrade. I have an irrational feeling that GNU TLS update is too often major even when version says otherwise - I know this feeling is not a good reason for any actions, though. >other things should be done in a branch and submitted for review. This of >course depends on people exercising good judgment :-) I wonder if it is possible to give svn committers (we are known to be pairwise distinct, I guess) right to accept any pull requests but their own. This would enforce minial review while allowing any one person with five minutes to spare to click through simple upgrades. _______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
