[Nix-dev] Stable NixOS releases

[phreedom at yandex.ru]

On Вторник 14 мая 2013 15:54:04 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.

It is possible for example for the liveCD to be broken as such and it's a very 
very bad thing. Also, you have to understand that even though we don't 
currently target a stereotypical "granny" user, even advanced users still 
experience a cultural shock when they try NixOS, and we shouldn't 
unnecessarily blow it out of proportion.

> 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).
How about: if a given stable branch works for you, you can expect nixos-
rebuild switch to not break stuff? It isn't a guarantee that bugfix releases 
don't introduce bugs, or that new packages are bug-free. it's mostly about 
being able to seamlessly receive important fixes, instead of  monitoring the 
commit log, mailing list and issues to pick a good time to make a major 
update.
> 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.

Obviously users should be encouraged to run master, so that we received 
feedback faster. And in a sense, stable releases might look like we are trying 
to compensate for real or imaginary lack of users' git-fu. However there are 
many different user profiles such as :
* tester. always tracking master.
* newbie. wants to get a working system as fast as possible and with minimal 
hassle.
* agressive-conservative: postpone updates if major stuff happens(like x branch 
merge or kde version flip) till the user has the time to test, try to fix and if 
it fails, revert.(that's my main lappy)
* lazy. if it works, don't fix it. Could even match some developer profiles who 
only touch "leaf" packages.
* production. I described such a profile in my earlier email.

I can see newbie, lazy and production profiles getting some benefits without 
draining significant developer resources(or maybe even saving them, since 
production people can simply make a common public branch as opposed to a large 
number of private branches) as long a we don't make overblown guarantees.