[Nix-dev] Reminder about nixpkgs branches

[Vladimír Čunát]

Hi,
it's not at all so bad as it used to be. Last year it happened we had 
~10 months running stdenv-updates that was in the middle getting more 
and more breakages with added commits. That wasn't good and all agreed 
on that.

Extremely short (<1 week) one-topic branches may seem ideal, but 
currently they're very impractical, for several reasons:

1) Testing several changes at once is typically much easier than testing 
one-by-one, both in build-time and testing-by-using time.

2) Most people can't manipulate Hydra jobsets (including me), which 
would be needed for each mass-rebuilding update.

3) Sure I want features stabilized fast, but wishing it isn't enough. 
Moreover, how much a mass-rebuild change is potentially destabilizing 
can be tricky to estimate. For example, with freetype I tested building 
my whole system, including KDE, xfce and several gtk3 apps, and still I 
didn't discover dozens of build regressions until Hydra tried building 
all. Those took me a few whole days of work to fix.


On 07/23/2014 11:29 AM, Mathijs Kwik wrote:
> - staging hasn't been merged for > 2 weeks
That's good, as there are quite a lot of build regressions ATM.

> - big long-running x-updates branch  [...]
This iteration of x-updates runs for about 5 weeks now (since June 16), 
which isn't so terribly long. Also, note that it started *before* the 
staging branch was even announced (~week after that), so I was now 
finishing it in a-kind-of old-style workflow.

Note that there are no added stuff in x-updates like enlightenment. That 
got merged in from master and needed a fixup after x-updates changes.


> - upgrades that will probably break stuff
>   - add the new version to master
>   - users and maintainers can try if their packages work with it
>   - change the default in a separate branch (ex: gcc-upgrade)
>   - or change the default and pin breaking packages to the previous
>     version

I don't remember agreeing on anything like adding updates as new 
versions instead of changing the old one (maybe I misunderstood you). I 
rather think it would tend to create a high version bloat (think ffmpeg 
and worse), as maintainers will rarely be so responsive to update the 
dependency to newer.


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/20140723/8d3fc3c0/attachment.bin