[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