On Monday, December 09, 2013 11:56:06 PM Mathijs Kwik wrote: > I think that "watch out for causing rebuilds" should not be a reason for > committing stuff to some other branch (and waiting 6+ months for it to > be generally available). If rebuilds are an issue, I think they should > be tackled in hydra somehow (low prio for these changes) or - if that's > not around the corner just yet - be put on a very short-lived (1 or > 2)weekly-merged "causes-rebuilds" branch, instead of to a "this might > break a lot of stuff so we make a big project out of it" branch.
It isn't simply about rebuilds. Rebuilds is an indication of the scope affected by the change. If the scope if large, you are almost guaranteed build failures and breakage. Sometimes, even runtime failures, disappearing dependencies and other nastiness only detected at runtime. I'm experimenting with semi-automated patching workflows, with commits going to master directly right now. The destabilization of master is quite noticeable. The biggest reason for this is that changes that are too deep start affecting stuff you don't maintain and aren't familiar with, so the breakage is inevitable. One of the possible reasons why you are happy running those "major upheaval" branches is that they are close to being stabilized and merged. _______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
