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.
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.- big long-running x-updates branch [...]
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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
