What should stable NixOS prioritize?

Development
1

Problem

Our stable releases cover a large breadth of use cases, this discussion is talk about what should be prioritized for a stable release. And perhaps optimize our release schedule to align with meeting those core criteria.

Context

With the 20.09 release, the biggest delay was around polishing the plasma5 experience, with the last blocking item being closed 3 weeks after the original release date: [20.09] kdeFrameworks.plasma-framework: aligned with QtQuick 2.12 by jonringer · Pull Request #101078 · NixOS/nixpkgs · GitHub

Why is plasma given so much precedence, even though it’s only one of 17 Desktop managers available?

Because we distribute plasma as our official graphical installer iso (soon to be accompanied by a gnome iso as well). For NixOS desktop users, this is largely going to be their first impression and face of NixOS.

Defining target audiences of the stable release

(This is my personal thoughts, but I’m not an expert in release management; and I don’t have any actual data to back up these assumptions)

The main users for the stable release can broadly be described as, “don’t want to deal with the constant minor breakages in unstable”. More specifically this is likely to be two groups of individuals: people using Nixpkgs in production, and people using NixOS as their daily-drivers.

People using nixpkgs for production don’t want to deal with having to constantly deal with changes in their underlying technology stack, and want to a way to have the latest non-breaking versions for security.

The other large group would be people who use NixOS for their daily driver and want their desktop experience to just “always work”. They are willing to give up having the “latest and greatest” version of a given package for not having to deal with a package being potentially broken.

How do we satisfy these target audiences?

Production Users:

  • policies around what will get backported to prevent default versions being bumped
  • release notes with upgrade instructions and incompatibility notices
  • Upgrade pains are only experienced when switching release channels.

Daily Driver Users:

  • Provide working desktop experience

Both Users:

  • Provide a wealth of usable packages
    • Mostly accomplished through development on unstable and ZHF

How do we fail to satisfy these targets?

Production Users:

  • Since their use case is around minimizing version instability, I think we already do a reasonably good job in providing a good experience through the current back-porting conventions.

Desktop Users:

Goal of discussion:

Propose solutions to avoid stabilization complexity. Possibly result in an RFC to change NixOS release schedule or procedures.

19 Likes
2

Personally, I think there’s 2 avenues we could go:

Optimize for people’s time:

  • Move the release to be YY.05 and YY.11
  • Provides ample time for the latest gnome and plasma DM’s to be packaged. Also allows for the related ecosystems to also support those releases. Major distro’s which specialize in shipping a specific DM will likely have fixes for the issues we encounter
  • This essentially “aligns the release around unstable and external ecosystems”

Optimize for current YY.03 and YY.09 timeline:

  • any fundamental package which has many dimensions of compatibility (glibc, gcc, llvm) should be merged in with ample time to address regressions in unstable (e.g. a month). Otherwise they should be put off until after a branch off. (We saw 3 staging next PRs which added 500 staging commits a few days before the target 20.09 branch-off date; which did hurt the release schedule). Discussion around staging/staging-next convetions should be done in Fixing the staging/staging-next workflow
  • systemd will have to align with the version of gnome and plasma we will ship.
  • However, this will cause more divergence between the two branches (if the critical packages get updated after branchoff, then the two branches could exhibit different regressions), and ZHF may suffer.
  • This essentially “aligns unstable around the release”

Personally, I’m in favor of pushing our release back two months, so that the Desktop ecosystem is likely to be much more manageable. For production users, they will still have the 6 month cadence, past the initial push back.

12 Likes
3

I may be worth considering having separate server and desktop editions of NixOS. Their needs are pretty fundamentally different, so having different requirements for their releases makes sense. It would also set a precedent for other potential editions, like mobile edition or embedded edition, if that’s something we want.

4

Each edition we support still cost someone time and effort. And fractures the experience as a whole. I think the desktop and devops usage is aligned enough for it to make sense. I just wish it wasn’t so painful (plasma+kde+qt doesn’t make it easy).

3 Likes
5

+1 to YY.05/.11 plan, with requirements to core packages in YY.03/09 plan if appropriate.

Core packages (I mean): kernel + the C standard library + C and C++ toolchains + PID 1 (+ display servers?), at least. C and C++ toolchains are especially critical of course, as everything will be broken awfully if they are broken.

6

Yeah Jon those dates are actually nice. I was thinking for the past two releases ~these dates aren’t soo great for us~, this would optimize things for a much better nixos IMHO. Currently the thing is, we cannot control what people can do to a scary extent :rofl: or expect them to perfect align unstable with release. Also, we’ve been releasing months (though our number is different) the same as ubuntu… So I’m +1 on 05 and 11, but we should go through lots of feedback that these dates are actually going to be better in a clearly defined manner. I really don’t think changing the date to what NixOS releases is a big deal as long as it’s spaced out appropriately and maybe adjust EOL.

5 Likes
7

Just to give you a datum as both production and desktop user: you’re on point with my usage characteristics and upgrade preferences.

4 Likes
8

I think another worthwhile discussion is whether releases could be yearly rather than twice a year.

Benefits: less of a burden on release managers. Enterprise users probably like a longer-term stable base, some desktop users likewise.

Downside: NixOS is less fresh. But this is a smaller issue than most other distributions, since it is so easy to cherry pick packages from any nixpkgs revision.

4 Likes
9

Another down-side is that the maintenance would more expensive. When you backport a fix, there’s a difference if the codebase is three months or six months old (on average), even if I disregard the possibility that you may not need to backport some stuff thanks to shorter support time.

EDIT: I should add that at least in terms of open CVEs we already seem rather undermanned in this respect, though I expect most of these are not that “severe” and many others have been fixed but not marked so.

2 Likes
10

I think the reasons there are mainly historical. IIRC, once upon a time Eelco based the first graphical ISO on KDE (was it 4 already?) because… it was the DE he was using? Anyway, as usual, much power lies in hands of those who are willing to do the work and maintain the DE/ISO. Having an official image for a DE will add some motivation but probably not enough by itself to keep it in good shape, so I believe it primarily needs dedicated maintainers. (I’m convinced such things are not for the release managers to do, because they have too much to do already and typically can’t even do all that on full time.)

In case of graphical ISOs there are additionally significant costs to infrastructure, as frequent rebuilds of the images are relatively expensive (e.g. lots of S3 storage, as there’s no sharing among the large images). At least that’s how it used to be discussed, maybe some garbage-collection changes can improve that relatively easily.

1 Like
11

Release dates (minor consideration): I think it was advantageous for publicity to release before the Ubuntu family, and releasing soon after them may be the worst in this respect. I don’t think I’m good at PR, so I may be wrong or the real effect may be totally negligible. I’m not aware of other SW than GNOME ecosystem being significantly aligned to Ubuntu schedule, but it is possible there are more (now or in close future).

12

If I am representative of a typical desktop user (which I don’t know), there might be slightly different accent here. I use stable mostly because it is default, I haven’t really considered whether I should use unstable.

That said, I definitely feel friction because some important for me packages lag behind (notably, editors like VS Code and JetBrains IDE). I think the de-facto practice is that updates for those are backported to stable, but with a noticeable delay.

So, maybe more of the daily-driver folks should be using unstable, and it’s a question of renaming it to “rolling” or some such?

7 Likes
13

Fedora is literally the GNOME schedule so there’s that too.

14

Currently the two yearly releases aren’t the best for desktop users because they EOL a month after the new release. It’s useful for desktop users to actually be able to skip a release and still be in good shape. But that would be a much bigger change, and having feasible milestones helps us to work towards a polished goal. A good example is for Pantheon. If we were to go rolling for these types of users Pantheon could never be polished because it breaks as soon as the GNOME base does. So having that frozen stack of software also helps for desktop maintainers as well. The issue with your packages lagging behind is actually related to the release maintenance, all of those updates are usually okay to backport and should be (for a while actually I was backporting all the VS Code updates and telling the maintainers to do this… but when I wasn’t there to do that maintainers didn’t care to bother). So that issue is maintainers aren’t keeping the release fresh and they really should. I try to do stable updates to NetworkManager on releases and for actually all the things I maintain where it’s feasible. In other distro’s having ports to their stable releases is actually a bigger deal, I’ve noticed, so maybe we could add this to our documentation as a “maintainers responsibility”. GitHub actually has actions to create backports, so maybe if someone makes an RFC for that backporting your changes will just be a comment to create a PR and automated checks.

6 Likes
15

That would inherently require to increase the (average) number of releases supported at once, i.e. additional people maintaining releases (and other) resources.

16

true, I hope one day this could be a goal or we could investigate other models. Currently we couldn’t do this at all.

17

Hi all!

I suspect, without proofs, that NixOS users are a little bit more
server than desktop, however I’m pretty convinced, again without
proof, that most NixOS users are “expert enough” to choose their
own environment(s) so the official ISO is probably mostly used by
new users to made their first NixOS personal deploy.

Create custom ISO, at any point in time, for instance from stable
channel, embedding personal configs, is super-easy to a point that
passing through official ISO after the first time is not much
interesting.

If the above statements are true having official images/releases
with modern DE is a big work for developer and nothing much
interesting for end users. Users willing to use Kde or Gnome will
install it from their final config, regardless of the live default
environment, as any other desktop users for their favourite DE/WM.

A GNU/Linux “power user” could be interested in NixOS because of Nix
not because of Kde or Gnome default desktop experience. A newcomer
to GNU/Linux probably fail to use NixOS anyway since maintain a
config is not for that kind of users.

In release instead of ISO image terms, supporting Kde and Gnome is
something probably most users expect, even if they use some other
DE/WM, but the level of “polishing” might not be that critical.
Also personally I think that in a not so far future Gnome will be
GnomeOS, Kde will be something similar, so painful to be used
outside that most distros will drop them. Only an official distro
for one and the other will remain… They have go far past the
level of usability in *nix terms already…

Long story short IMVHO a default with something really neutral in
modern terms, like XFCE, it might be far simpler and made most
users happy enough. People like me using EXWM do not be much
annoyed by such “lightweight” desktop, People who like modern DE
would not be lost in XFCE, a default nice theme (like Xubuntu)
might be enough for all.

Local docs with an well visible “launcher” like NixOS manual and
NixOS Wiki embedded, a not so basic CLI apps selection, perhaps
zsh with a modern prompt, completers&c active, optional fish,
elvish, bash, few GUIs like GParted for people willing to work via
GUI, a modern lightweight text editor, nvim and Emacs, a GUI file
manager (Xfe like, Thunar, does not matter much), a Browser.
That’s IMO the best experience a new user might like, just taking
a look a /r/unixporn (Reddit) can be a good index of users mean
taste.

Also IMO instead of build two giant ISO (Gnome and Kde) a minimal
CLI iso, a light GUI iso and an optional zfs iso to avoid questions
about zfs license, can be better for most users. Taking a look at
System Rescue (formerly SystemRescueCD) software selection can be
another good example to take.

Offer pre-made code to generate a custom ISO, encouraging that
practice, offer pre-made configs for LUKS+LVM+zfs, zfs directly,
with or without crypto, [LUKS+]LVM+zfs, [LUKS+]LVM+btrfs would
be a very nice addition.

I doubt that in the near future NixOS, while growing, will be a
“mainstream top distro” like Ubuntu, Fedora or Arch, so try to
“compete” in their terms is not much a battle worth doing. NixOS
goals are reproducibility, robustness, “buil-in IaC”, NixOps,
Disnix, … the rest is only obligatory boilerplate aside.

Sorry for the length and bad English…

– Ingmar

5 Likes
18

I think the people that are aware of NixOS will want to try it out regardless if it was released a month before or after Ubuntu.

Since we seem to need a month to stabilize around our “weird mix” of package versions, we never release on time anyway. So, being “ahead” of Ubuntu never actually occurs.

19

I think usually we released a little ahead of Ubuntu, even if it was a week or two behind the targeted month.

EDIT: of course, if we want to keep the timing, it seems easy to do the fork-off earlier… regardless of which month is targeted.

20

Another option would be to de-prioritize the desktop managers, and get the release out the door in a timely manner. However, I don’t like this as it makes the “stable” branch not really stable.

3 Likes