Stabilizing 18.03 Impala

[Vladimír Čunát]

Hello Nixers!

Impala got branched from master on Monday. There was delay against the
plans, partially due to some last-minute upgrades that we wanted (e.g.
nix-2.0). I also cherry-picked all seemingly suitable commits, pushed
to master or staging until some point of today.


## Schedule

We want Zero Hydra Failures at the release point as usual! See
https://github.com/NixOS/nixpkgs/issues/36453

Note that 18.03 is planned to EOL in October 2018, and it supports three
platforms: x86_64-{linux,darwin} and newly aarch64-linux. Also, the
support (i.e. cherry-picking) to 17.09 still runs in parallel at least
until the start of April, and for important security fixes at least
until the end of April.

In case there are enough *volunteers*, you may team up and promise some
form of 17.09 maintenance beyond that - I'm sure Hydra can handle it
well. (At least for x86_64-linux, but I don't expect you would be
interested in other platforms for this.)


## Maintenance workflow

Everyone with push access: since this release cycle I would really like
that *you* (and authors) decide and perform most of the cherry-picking
to stable releases - just do `git cherry-pick -x <commit>` immediately
when the change gets to master or staging. (I probably mentioned this
on the last NixCon.)

What should be cherry-picked?
- Certainly all security patches which aren't major updates. If a
security patch is a major upgrade, try and find minor updates or patches
for our current version which fix the same vulnerability. Apply the
major update to master or staging, and the minor one to stable.
- Any updates when the current version on stable is broken. A key
example of this is Spotify, who regularly breaks their old versions.
- Extremely security-sensitive software, in particular Chrome, Chromium,
Firefox, Thunderbird, and of course kernel minor bumps.
- Bugfix-only updates (minor, maintenance). Generally be cautious about
these. Backporting is optional if the fixes don't seem important; we
don't want to risk breakage if there's little to gain.
- Optionally, new package additions, as that won't break anything.
- If in doubt, /cc me and Frank (@vcunat @fpletz), but please, first try
to decide only among the participants of the PR (including the package
maintainer).

I have mainly two reasons for this explicit request.
(1) decentralization: it's similar to the reason for the nix-core team.
The community is too big for some responsibilities to lie on a single
person - or a team of two in this case, especially as both Me and Frank
mostly do this in our free time.
(2) overall efficiency. It's typically the authors, reviewers and
maintainers who have the best information whether a change fixes
security issues or breaks compatibility.


--Vladimir

[Judson Lester]

I'll admit to some trepidation wrt to 18.03 and Nix 2.0 because of https://github.com/NixOS/nix/issues/1934. To be clear: installing Nix 2 on my NixOS system left me unable to actually install or uninstall software with nix. I had to dig out the old nix-env from my /nix to uninstall it. I have no idea how to proceed with this issue.

Judson

--
You received this message because you are subscribed to the Google Groups "nix-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nix-devel+...@googlegroups.com.
To post to this group, send email to nix-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nix-devel/51f0dc99-7f05-8db3-ca66-75d6e5d56095%40gmail.com.
For more options, visit https://groups.google.com/d/optout.