[Nix-dev] new possible movement to git (?)

[shea at shealevy.com]

> Hi,
>
> On 08/24/2011 11:02 PM, Shea Levy wrote:
>
>> It has been over a year since this discussion and I have not seen any
>> move toward implementing the suggestions in the thread. If this is
>> simply due to inertia, I would like to offer up help similar to what
>> Marc Weber offers in his initial email (migrating scripts, providing
>> advice to users, etc.). If it is because the NixOS community is
>> undecided as to which vcs to switch to, perhaps we should have a
>> discussion about how to fairly discuss and decide such things?
>
> I've been meaning to set a Git migration into motion for a while, but I
> haven't really been able to find the time.  (Or the motivation, really -
> I don't seem to be suffering from Subversion to the same extent as other
> people...)
>
> Anyway, to make a switch to a new DVCS more worthwhile, I'd like to use
> it as an opportunity to improve NixOS/Nixpkgs stability.  Right now
> doing an "svn up" is rather dangerous, since the trunk it quite often in
> a broken state.  Also, the binaries in the Nixpkgs channel lag behind
> the Subversion repository, so doing an upgrade may require building lots
> of packages from source.
>
> So it would be nice if we had a more stable tree that users can update
> from safely.  For example, we could have these Nixpkgs/NixOS
> trees/branches:
>
> - An "unstable" tree which receives developer commits.  It might be in a
> broken state, so end users shouldn't use it.  Hydra continuously builds
> it.  Of course, complicated changes should be done in a feature
> tree/branch and pulled in when they're done.
>
> - A "tested" tree that automatically gets updated from the "unstable"
> tree when some set of Nixpkgs and NixOS tests succeed *and* the Nixpkgs
> channel is up to date.  This tree should be fairly safe to use.
>
> - A "stable" tree that gets updated manually and conservatively (e.g.,
> only security or stability updates).
>
> Does this sound reasonable?

Sounds good to me. A few questions:

1. Would we still need stdenv-updates, or could we just use feature
branches for the individual update we care about then merge it into
unstable (or probably master in keeping with git lingo)? This would put
rebuild work onto developers but since users should be using "tested"
they'll never have to manually rebuild their system (though they will have
to download it).

2. How does hydra decide which builds to add to its queue? If it only adds
based on the latest commit in unstable, couldn't a steady enough flow of
commits mean it never has a completely built channel for any given commit?
Would there be a way to force hydra to try building the whole channel for
a fixed commit if the tests pass or something like that?

3. I like the idea of stable, but given the current development
environment I think might go stale unless there's some sort of automated
way to tell us to think about merging from testing at a particular point
(e.g. it has been 6 months since the last major update on stable and
commit 123456 of testing has passed a full suite of tests, so send an
email to the maintainers of stable to remind them to start the process of
updating stable).

4. I'm not really sure which would be considered better practice, but
couldn't the "testing" branch be accomplished with tags instead of a
separate branch? From my understanding of your explanation, testing will
always be a fast-forwardable subset of unstable, so it doesn't need to be
its own branch. This doesn't apply to stable, since it will receive
cherry-picked security updates between merges.


>
> About where to host the repositories: we could do it on nixos.org, but
> using Github is rather nice because then I don't have to manage users or
> set up a web interface, and the pull request management seems rather nice.
>

I just assumed you'd want it on nixos.org, but I'd definitely prefer
github. It does all the hard work for you.

>
> Random point: should the NixOS and Nixpkgs trees be in the same
> repository?  I think so, since it allows them to be updated atomically,
> which is important given that Nixpkgs and NixOS changes are often related.
>

It's probably overkill to have them in the same repository. They currently
are in the same repository and they almost never receive simultaneous
updates, but on the occasions where we might want to there is a tool
called gitslave that might help: http://gitslave.sourceforge.net/

> --
> Eelco Dolstra | http://www.st.ewi.tudelft.nl/~dolstra/
> _______________________________________________
> nix-dev mailing list
> nix-dev at cs.uu.nl
> https://mail.cs.uu.nl/mailman/listinfo/nix-dev
>