[Nix-dev] branches and rebuilds

[Mathijs Kwik]

Hi all,

I would like to give my opinion on the current "flow" we seem to have
and would like to hear your opinions.

I've been trying to find my own flow of staying up-to-date, submitting
changes and keeping my unplanned nix-improvement/fixing time below a
certain level. To do this, I've been creating my own "stable" branches
on a monthly basis, while only doing "master" stuff when I have some
time, and only in a virtual machine, so it doesn't disrupt my normal
setup.

Like many others, I soon needed stuff that was only available in
stdenv-updates (like gcc 4.8) or in x-updates (llvm 3.3). In both cases,
there wasn't a real reason for those to be in a separate branch, as they
could just as well be pushed to master, without switching the default
just yet. Anyway, I decided to just merge x-updates into my master and
fix the stuff that broke for me. 

Usually, stuff was easy to fix by upgrading or adding some patch, but in
problematic cases I just added the previous version from master and made
problematic packages use these. Same goes for x-updates.

In the end, everything worked fine and I've actually been running with
stdenv-updates+x-updates for 2 months now. I have some upgrades and new
packages, but committing them back to nixpkgs becomes more problematic
now, because I need to check whether they still work on master or
whatever branch. They might depend on something that's only in 1 branch
yet, or break with the old/current versions available.

I think others will recognize these things.
Now, what bothers me is the fact that these feature-branches seem to
live like a full year before getting merged, and stuff gets piled onto
them, just to avoid rebuilds on master. Other reasons might be that
developers themselves are running and testing these branches on their
every-day systems so it's actually easier to commit there because they
might not work on master yet.

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.

The fact that I've been running my stuff on stdenv+x for some time must
mean there aren't fundamentally broken :) "My stuff" is actually quite a
lot, as I build for a laptop, a desktop and 2 servers: LAMP, vpn, kde
desktop, parts of xfce, firefox, libreoffice, chromium, node+npms, lots
of haskell libs/envs, bunch of databases.

I think these branches should just be merged and we shouldn't allow such
long-running branches to spring up again. First of all, we now have a
stable branch. Furthermore, with nix, it's almost always easy to quick
fix some important package by just keeping an old version of some
dependency around. Of course maintainers should focus a bit on keeping
these separate versions to a minimum (hello boost and ffmpeg :), but I
think it's way better to just upgrade something and find 90% working
(sticking the 10% to the old version) than to have 90% wait for the
other 10% to get fixed. Keeping things more as 1 codebase will improve
the general workflow. Massive find-and-replace style changes won't just
be applied to 1 branch (leading to merge conflicts, or "forgetting"
stuff that will get merged later) and because people see "future" work
in 1 place, it's probably more clear to them that the patch they are
adding to version X should also be considered for version Y, because
otherwise it will be lost when Y becomes default. Currently, Y is in
some other branch you haven't payed attention to yet, so it's up to the
people working on that branch to find out about your patch and be smart
enough to apply it to their current version as well. But most people
(including me) who merge master into some other branch only fix merge
conflicts and don't bother with logic like "this got applied to all
things X, we have an additional X in our branch so that should probably
get it too". 

All in all, I think we currently have too many "tools" to make sure
stuff won't disrupt anything else. In my eyes, this complicates things
more than we get back out of it. I would rather see master turned into a
more hack/break/fix style branch, with only short-lived (1 month?)
feature branches that are really just there for 1 thing and are not
abused just to save rebuilds. People can always decide to work from
stable + their own cherry-picks if they want a bit more stability. Of
course there should be some rules like a "stabilization period" before a
new stable release, say 1 or 2 weeks where people are not allowed to
push anything disruptive. Also: breakage should be avoided mostly, so no
pushing of half-finished changes. But pushing some upgrade (which you
test yourself with 1 or 2 dependent packages) to see what breaks, to
then quickly try to fix (by keeping the previous version around for the
problematic packages or by rolling back your change) is ok.

Anyway, this is just my opinion, so please don't take my words as
"someone announced we should work this way" :)
What would others prefer? Am I alone in perceiving these issues?
Other solutions? Let's discuss some.

Mathijs