[Nix-dev] Reminder about nixpkgs branches

[Mathijs Kwik]

Some time ago, there was some discussion about stdenv-upgrades and
similar long-living branches.

I believe we decided:
- we would like short-lived, single-issue branches, like:
  - glibc upgrade
  - changing the default gcc version.
- new packages should just go into master
- upgrades that will cause lots of rebuilds, without expected breakage
  go into "staging"
- upgrades that will probably break stuff
  - add the new version to master
  - users and maintainers can try if their packages work with it
  - change the default in a separate branch (ex: gcc-upgrade)
  - or change the default and pin breaking packages to the previous
    version
- for releases
  - default version of a package = latest version
  - packages that cannot use this latest default should be pinned to the
    older version
  - we want this inside all-packages.nix, so it's clear in 1 file which
    packages need fixing
- "staging" is only meant to give hydra some headstart
  - a big queue in hydra for master means people cannot easily test/try
    their changes
  - reacting to security patches cannot be given priority if there's
    already a lot of changes building for master
  - staging should be always mergeable
  - staging is supposed to be merged every 1 or 2 weeks


I'm sending this email because I noticed a few things.
- staging hasn't been merged for > 2 weeks
- big long-running x-updates branch
  - contains a lot more than just xorg upgrades
  - upgrades to qt and lots of other non-core-x11 packages
  - new packages / enlightenment
- LLVM 3.4.2 hasn't been available in master for 1 month+
  - I understand xorg/mesa depends on it
  - Why not add it to master, make mesa use the new version in x-updates?
  - If more packages are expected to break by changing the default
    shouldn't we just create llvm-upgrade for that?


Not to complain :)
I'm on 14.04 with some custom cherry-picks myself, so I haven't had
issues with the above flow. It's just that I think we can try a bit
harder to stick to these guidelines, or discuss them a bit more if
people feel they won't work for some reason.

Feel free to share your thoughts!
Kind regards,
Mathijs