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

[Michael Raskin]

<4E5566E6.9050101 at shealevy.com> <4E5B97BE.5030406 at tudelft.nl>)
Mime-Version: 1.0
Content-type: text/plain; charset="UTF-8"

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

Of course, we will have to name stdenv-updates something new each time
to keep track of what got merged where afterwards.

>unstable (or probably master in keeping with git lingo)? This would put
>rebuild work onto developers but since users should be using "tested"

It doesn't look like we have large user-to-developer ratio..

>they'll never have to manually rebuild their system (though they will have
>to download it).

Maybe we still want these feature branches to be relatively long-running...

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

Currently Hydra builds some commit until it is completely built; then 
fetches new head. I see no reason not to keep it this way.

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

The problem is that "hydra-built" will never be in the position of passing 
set-theoretically more tests than last time - some packages are broken by
gcc updates...

Anyway, currently average release seems less stable than average trunk 
revision.

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

Well, if you would like to track what happenned in some convenient manner,
it looks like you would need at least Mercurial-style tags (or, even better,
Monotone certs or Veracity stamps; note also that if you'd like to keep
set of "testing" revisions easily accessible for future reference, you could 
also do that via a Monotone-style where all commits coincidentally also 
belong to another branch)

This seems just to be a trade-off: if you want to use the tools git has over
Mercurial for creation of history, you get less tools for organizing history.

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

Maybe nixos.org could be a read-only mirror for github or bitbucket 
development repository.