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

[Michael Raskin]

>> <4E5566E6.9050101 at shealevy.com> <4E5B97BE.5030406 at tudelft.nl>)
>>>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?

Given that branches are mere pointers, I don't see how to find out what
was stdenv-updates before after it has been merged into trunk and re-created

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

An easy way to update to last completed Hydra build would be nice, true.

I guess small development would be easier to do against testing, with
subsequent merging. 

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

Maybe we should care about that when we have some new ideas on doing it right.

Or when we have enough developers to have up-to-date notion of what works,
what is easy to fix and what is broken fundamentally.