[Nix-dev] [***SPAM***] Nixpkgs and NixOS moved to GitHub

[Michael Raskin]

>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.