[Nix-dev] Nixpkgs and NixOS moved to GitHub

[Mathijs Kwik]

Eelco Dolstra <eelco.dolstra at logicblox.com> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20120621/b0e9378e/attachment.bin