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 _______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
