[Nix-dev] branches and rebuilds

phreedom at yandex.ru phreedom at yandex.ru
Tue Dec 10 10:41:10 CET 2013


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.


More information about the nix-dev mailing list