Eelco Dolstra <[email protected]> writes: > Hi all, > > I've completed the migration of Nixpkgs and NixOS to GitHub. This means that > the reposities > > https://github.com/NixOS/nixpkgs > > and > > https://github.com/NixOS/nixos > > are now the "official" Nixpkgs and NixOS repositories, respectively. I've > set a > pre-commit hook in the Subversion repository to block commits to the old > Nixpkgs/NixOS trees. > > Please use GitHub's integrated bug tracker. It has the advantage that you can > refer to or close issues from commit messages (e.g. a message containing the > string "Fixes #21." will automatically close issue #21). > > 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. > Although I've only used Nix* for half a year, I haven't seen many commits being reverted, so in general I think the current "members" do a pretty good job of thinking things through, and communicating about possible issues.
And of course Nix helps a lot. If something does break, usually no harm is done, just roll back / boot into a previous configuration. I think this centralized "open" workflow helps rapid development and rapid responses to issues / requests on the mailing list. In my experience with other distributions (although much larger and targeting a different userbase), it became a pain quite quickly to deal with simple package upgrades or adding a dependency/optional patch somewhere. A lot of bureaucracy to decide about every change and even then some more bureaucracy about when it will be included. Maintainers being on vacation, or just stubborn about change in general, it all takes a lot of time. Nix*, by nature, feels very different. Having the entire source tree easily accessible/forkable changes a lot already. It's easy to just do your (local) changes, and have git take care of merging it with "official" updates/changes. However, I think that giving people the ability to commit those changes directly into master, will - at least with our current size - help Nix* move forward the fastest. If every contribution would have to be packed up as a pull request and reviewed, I'm pretty sure a lot of (probably useful) contributions will just end up in forked repositories, because the contributors themselves don't think it's that useful for others yet, or they want to bundle a batch of changes before making it into a pull request. So I'm all in favor of having people just commit whatever they want (once they've proven they somewhat know what they're doing). If others don't like certain commits, roll them back and have some discussion. Nix makes sure that any screw-ups never harm a system beyond repair (just simply roll back). This is the "master" branch we're talking about here (or a certain feature branch). So, blindly tracking it, without reading commits, and expecting everything to just always work out fine, just won't work. You want to track master? You do some reviewing. If this "open" policy scares people, we can switch to a master/testing/stable scheme. (testing following master roughly a week behind, stable one month or so). That creates some overhead of course, but I think it's less overhead compared to checking every individual pull request, and it at least makes sure everything is included (pull requests being forgotten / just too busy). > - 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 > other things should be done in a branch and submitted for review. This of > course depends on people exercising good judgment :-) A hybrid sounds good to me. I think the judgment will work out fine. Just my thoughts about this, but I'm fine to go with whatever workflow in the end. Greetings, Mathijs
pgpNofDDqeJZp.pgp
Description: PGP signature
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
