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

[shea at shealevy.com]

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

Why would that be necessary?

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

No, but as a developer I would have unstable checked out where I do my
work, and as a user I would have testing checked out in /etc/nixos or be
subscribed to testing as my channel.

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

Ah, I wasn't aware that was how it works. So as long as it doesn't gc the
results too soon, the current setup is fine.

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

So do you think there should be no stable branch at all? In a hypothetical
future where we have hundreds of users who are not all also developers,
would they be using the latest nixpkgs all the time?

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