[Nix-dev] branches and rebuilds

[Vladimír Čunát]

On 12/09/2013 11:56 PM, Mathijs Kwik wrote:
> I would like to give my opinion on the current "flow" we seem to have
> and would like to hear your opinions. [...]

I think it's generally agreeable that rebuilds themselves aren't a 
reason to keep stuff long out of master, especially now that we have the 
stable branch(es) (cf. discussion 
https://github.com/NixOS/nixpkgs/issues/1317). AFAIK just rebuilds were 
never a reason to keep stuff for longer than around a week (Hydra 
finishing). The problem is that typically some things get broken, apart 
from some others being fixed. These don't even need to be build breaks 
but some subtler problems (like currently NetworkManager not connecting 
to encrypted networks in master), and it's not clear if it's mostly 
better with the change or without it (until some things get fixed).


[general workflow]

This may be just my personal opinion, but I would prefer not too much of 
hack/break/fix-style on master. Sure, most of commits isn't likely to 
break more than to fix and it should go immediately to master (e.g. 
after plain build-test of the package itself).

Sure, I do prefer as short iterations as possible, but if it seems a 
change breaks more than fixes and people don't have time for it, then we 
get the long-term branch and it just can't be helped (well, it could be 
just reverted). I think the key here should be to have *separate* 
feature branches, so the other changes don't get dragged with it (like 
on the current stdenv-updates).


[current branches]

AFAIK the only really-long-running branch with many changes is 
stdenv-updates. It's about 9 months now, it has been a great mess at 
times; I don't know the current breakage status currently, but I think 
it's close to being mergeable (although last time I checked there was 
even binutils with references to bootstrap-utils).

x-updates: (as I'm committing most of x-updates nowadays,) currently it 
lives about two months (note that e.g. llvm-3.3 is even in release from 
its start). Why separate: major X-server update, etc. were potentially 
dangerous, and it did cause a few build problems (which I didn't have 
time to fix immediately); being separate allowed me to *find* build 
breakages without breaking master.

Now the only potential reason for not merging x-updates to master is a 
[mesa-9.2.* bug], where I don't have a clue about its impact; I suppose 
we can risk it, as it's e.g. in Arch and Ubuntu Saucy.

[mesa-9.2.* bug] https://bugs.freedesktop.org/show_bug.cgi?id=67672


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/20131210/c0a0c1b5/attachment.bin