>>> <[email protected]> <[email protected]>) >>>>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. > > _______________________________________________ nix-dev mailing list [email protected] https://mail.cs.uu.nl/mailman/listinfo/nix-dev
