[Nix-dev] Stable NixOS releases

[Vladimír Čunát]

Hi.
Yes, I do agree we need at least one more "user profile" that is more 
stable than master. I took my time to think about this for two days; 
here is the result which sketches how it could look like:

- "master" branch
     * immediately gets all updates not likely to break a lot of things 
(like after one testing run)
     * huge or dangerous updates are first in experimental branches 
(e.g. stdenv-updates)

- "stable-YY.MM" branch
     * gets every *important* bugfix-only/maintenance update after 1--2 
weeks of testing (using it)
     * RC is created every ~3--4 months by taking ~2 weeks old master + 
all bugfix-only/maintenance updates since then
     * release after a few weeks (so major changes are > 1 month in use)
     * only one is maintained at a time (so it lives ~3 months)
     * after EOL it still receives security updates for another ~3 months
       (could  be longer for some of them, we'll see)


Reasons:

- Why create many-month longterm: security-only updates are quite 
infrequent, important for longterm releases, and it's usually very easy 
to integrate them (just change version+hash). They should almost 
certainly create no new problems and committing to multiple branches 
will usually be just a cherry-pick.

- current stable-* should make a good balance for most users:
     * relatively new features (lag 0.5--4 months behind master)
     * immediate security fixes
     * quick but tested *important* bugfixes (after 1--2 weeks)
     * not a high disk-space bloat like when rolling on master (bigger 
rebuilds only every ~2 months on average)
     * some time after EOL there are still security updates at least, so 
the users aren't too much pressed to switch at the precise moment

- Master should be the place where *most development occurs*. We want 
all "relatively safe" updates here immediately, so we can more easily 
find unexpected/hidden problems. However, keeping a whole system on 
master isn't for everyone, as it is e.g. quite HDD-space-intensive: for 
libs like gtk+, systemd, qt4,... maintenance update with full rebuild 
can take a gigabyte of space... and we do a similar thing almost every 
week in master.


Update workflow:

- Security-only fix: (check it builds,) immediately apply to master, 
cherry-pick to the current and the last EOLed stable-*.

- *Important* bugfix-only/maintenance updates: (check it builds,) 
immediately apply to master to test it. After 1--2 weeks cherry-pick to 
the current stable-* (such updates also IMHO almost never depend on 
changing other packages).

- For the workflow it might be very useful to agree on some code-words 
in commit messages, so we can easily/automatically recognize e.g. 
(important) bugfixes (useful when creating RC).


Notes:

- All above is probably only suitable to the two x86*-linux 
architectures. IMHO the others are currently getting so little testing 
that we can't really say anything about stability.

- Non-default versions of packages will probably live in a more free mode.

- Channels should again lag behind the corresponding branches (waiting 
until hydra rebuilds the version).

- I assumed that the changes committed to master are *used* by 
someone... which doesn't always hold for libraries: there are many cases 
when updating a thing breaks others and we don't find out for a long 
time. I don't know how to solve such problems... we could make libraries 
lag longer or something, enable more automatic tests, but we'll probably 
not completely avoid this.


On 05/14/2013 06:44 PM, Eelco Dolstra wrote:
 >> How to do it? I'd prefer not use github pages - while it would work
 >> I'd like to introduce branch specific info files - such as
 >>
 >> ./BRANCH_INFO.txt
 >>
 >> to which a summary of the important changes could be written.
 >
 >   I'd suggest putting the release notes in the NixOS manual or maybe 
on a wiki page.

I believe that keeping the list of major changes inside git tree is 
better. We could use this practice everywhere, even in master, so e.g. 
by "git log CHANGES" one would see important commits, etc.


On 05/14/2013 05:33 PM, Eelco Dolstra wrote:
 > But the risk with this approach is that people will be tempted to 
squeeze in
 > wildly destabilizing changes at the last moment:-)   I don't think 
this needs a
 > lot of bureaucracy or rules though, just some good sense not to (say) 
merge a
 > major GCC update into master just before the release is about to be 
branched.
 >
 > Also, having release goals (as in "these are the features we'd like 
to have in
 > this release") seems like a good way to focus development (and to get 
people to
 > volunteer to work on those features).

Yes, +1 for release goals and slightly "vague" rules for what can be 
included.


On 05/14/2013 03:54 PM, Marc Weber wrote:> Excerpts from phreedom's 
message of Tue May 14 15:44:24 +0200 2013:
 >> It isn't only about production. I'm sure that we managed to scare 
away some
 >> newbie users with a temporarily broken master branch.
 > I don't understand why, because nixos is the *only* distribution you can
 > just use older revision and continue. So it should even make those newbe
 > users use nixos with even more joy.
 >
 > The problem is there are many packages - and there will be more - we
 > will not have a chance to test all of them (eg games) - so we should
 > define what we want to call breakage.
 > Eg breaking ati/nvidia proprietary drivers is bader than breaking a
 > particular game (for work).
 >
 > There will always be "new users" who find bugs .. So maybe the better
 > way is to emphasize that using nixos its a smaller problem compared to
 > other distros.

I believe the worst problem for newbies is that the initial setup of 
NixOS is very complicated (in comparison to major distros), and also the 
whole nix approach is very different (IMHO many people also don't 
understand the great surplus that nix brings). Probably those who are on 
IRC a lot can tell better ;-)

 > We simply don't have the man power to retest all packages over and
 > over again. We have to focus on the most widely used ones.
 > Its sad, but the truth.

True, noone has. We should use automatic tests as much as possible.
(The more extensive ones separately from building, I suppose.)


Vlada


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3251 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20130515/61498b9d/attachment.bin