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

[shea at shealevy.com]

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

Ah, I see. Yeah, it would be nice if git had information in commits about
which branch the commit was initially performed on. This seems like a
really simple feature, not sure why it doesn't exist.

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

Fair enough. It's not like the creation of a "stable" branch will be that
difficult in the future.

>
>