20.09 Feature freeze items #95475
Comments
jonringer
added
0.kind: bug
|
cc @maralorn about Haskell stuff as well. |
|
Roughly it should be master around the end of August as usual, right? |
|
Our current plan is to have the branch-off + ZHF date on 4 Sept. I'll make a more official roadmap announcement tomorrow. |
|
#94354 is blocking |
|
Looks like |
|
@aanderse It tries to compile a small program against It can be fixed short term by removing |
|
Just to mention it as a representative/maintainer of the php ecosystem. We've recently merged our deprecation of on old version that should be merged before 20.09. So for the php ecosystem we're good to go. Consider this message a confirmation that someone read the ping to that team in the posting. |
|
Not aware of any major outstanding blocking issues in the Rust ecosystem. The |
That should be the case |
@jonringer unfortunately that would remove functionality (automatic vmware monitoring) that some users may find important. I personally don't use that functionality, so I would accept that over a broken build... I have opened a separate issue to track this. |
|
According to the GNOME 3.38.0 roadmap https://wiki.gnome.org/ThreePointThirtyseven it's due Sep 16. So I believe this means we won't have the latest GNOME in the release. This is fine since we basically never do because our release time conflicts with theirs always. |
|
It was projected that xfce 4.16 would be available before 20.09 release, but it seems they need more time in their roadmap #81569. So xfce 4.16 will not be in 20.09. |
Why don't we release NixOS one month later? This will sync up with Ubuntu too. |
|
Could be, but there are many projects that we package, and so far I haven't noticed that a notable fraction of them synchronizes around some dates (like the Ubuntu schedule). EDIT: though perhaps this synchronization will happen – I see Fedora basically shifting to Ubuntu's schedule now (no idea if it's intentional). |
|
@worldofpeace do you know how big the GNOME breakage would be? |
|
Generally I wouldn't do such things, and for desktops in particular I don't anticipate sufficient motivation for doing that. Regardless of release dates, there's a notable advantage we have in comparison to the Ubuntu model: we do provide quite a usable rolling version. People that want the latest whatever can use |
I'm not sure if that's a good reason to push a date. Unless KDE, gnome, and the other big software suites decides to align themselves for that type of schedule, then may it would make sense for us to change so we could have the "latest" going into a release. However, it also takes time for downstream packages to fully support those versions, and it still takes time to ensure they are working as intended. It's going to be hit or miss whether a given month really affords any substantial opportunities given there's so many packages, and not everyone cares certain sets. For example, I don't use a DE, so I largely am unaffected by KDE, plasma, gnome, or other changes. And as @vcunat has mentioned, we have a very usable "unstable" channel if people really care about having the latest and greatest. And one thing NixOS can do which other distros usually cannot, is allow for a user to pick packages from different channels. (although, this is much more involved for a regular user) |
This become less involved with flakes. |
The amount of breakage when updating gnome can vary, but in general updating desktop environments etc. in nixos is very difficult because we don't really have an automatic testing to verify. Here's an excellent example of this issue #84634 (comment). There are bugs we haven't noticed for a while because it's a thing I don't use.
That is a major upgrade, and generally, in a stable distribution, it is something that couldn't be backported.
As for ever pushing our release a month forward to accommodate gnome's release (which happens in the *.03 in *.09 exactly btw), this still wouldn't be enough time because we lack the resources. I would agree with most things @jonringer mentioned #95475 (comment), but I do understand for a general user pov accommodating to have the latest just makes sense. I think changing the actual dates in which we "consistently try to aim for" should be done with a lot of reasoning. Though let's be real: NixOS 20.03 was a NixOS 20.04. But pushing the date to the month we actually are releasing on isn't going to make us more punctual either 🤣 . |
|
I see #87268 as blocking. I would love some input on what a good solution is (in the PR). |
|
I'd like to see the systemd updates from staging make it into master, so we can bring back the 5.8.x kernel. |
|
That one is very certain. |
|
I wonder what the @NixOS/acme team thinks about supporting the current ACME module for another release, when it would probably be best to be investing in #91121 asap. |
I for one would very much like to see it merged. Maintaining the "old" module continues to get more painful as more patches and bug fixes are added to address legacy behaviour. I've addressed all the issues I could find in Github and elsewhere, and having had it in production on my personal system for quite a while I haven't had a single renewal issue. |
|
To avoid spamming everyone with yet another issue, please add release items that are not in the current 20.09 release notes in the issue: #95765 |
|
Uh, it looks like we forgot about |
|
Not a blocker, but a TODO item once branched-off:
That image was supposed to be temporary on unstable, up until mainline Linux was able to boot on the Raspberry Pi 4, which is still not the case AFAIK. |
|
Shouldn't we rather fix the image by putting the RPI kernel Fork in it instead of mainline? |
Putting the RPI kernel fork in what? This is what the Raspberry Pi 4-specific image does already. The task is to remove the undesirable device-specific image from the stable channel. The sd image, by design, is supposed to be generic. The current Raspberry Pi 4-specific sd image derivation only exists because of the popularity of the platform, and demand. I still hold the opinion that it might have been a mistake to have it at all. If the platform can't boot using the standard boot methods (u-boot) and the mainline kernel, for the time being it's not worth the headaches of maintaining it in an official manner. |
|
I'm unpinning this as many of the items have been merged in before branch off, if they have not please add them to the 20.09 blocker project |
|
I'm going to re-pin this, as many items have been added, but few have seen progress in the past 3 weeks. Items that feel like they warrant delaying the entirety of the release please make a comment here with:
NixOS is a community of volunteers, let's reasonable about time exceptions on getting these issues resolved. As much as I would love to have all scenarios be a tier 1 experience, the reality is that it's just not feasible. Scenarios involving casual users with "vanilla" (E.g. plasma, gnome, other DEs) desktop needs and production users with security needs (E.g. postgresql) are the two big user bases that I think warrant delaying the release. But the purpose of re-activating this thread is to open a forum for discussing such issues. |
|
Unsure where to mention this, but would |
worldofpeace
added
the
6.topic: release process
|
Not as critical as I expected it to be, because redis defaults to protected mode when not bound to localhost and accessed without password. |
|
I wanted to land this feature, even though I know it's dead last minute #100199 |
|
In my mind #101099 is a blocker. Sorry if that was the wrong issue to post this. |
|
This issue has served it's purpose. With #101736 merged, I think this is good to close |
|
This issue has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/procedure-for-adding-haskell-hackage-package-to-nixpkgs/10106/4 |
and others
Pinging all language, framework, and ecosystem owners to consolidate feature freeze items for the 20.09 release.
Please mention any items you see blocking the 20.09 release in your given domains
Items brought up will be discussed in a Feature freeze meeting at a later date.
Nix/nix-cli ecosystem: @edolstra @grahamc @nbp @Profpatsch
Mobile: @samueldr
Nixos Modules / internals : @infinisil @matthewbauer @Ericson2314 @orivej
Nixos tests: @tfc
Emacs: @adisbladis
Erlang: @gleber
Go: @kalbasit @Mic92 @zowoq
Haskell: @peti @cdepillabout
Python: @FRidh
Perl: @volth
php: @NixOS/php
Ruby: @alyssais
rust: @bhipple @Mic92 @andir @LnL7
Darwin: @NixOS/darwin-maintainers
bazel: @mboes
blockchains @mmahut
podman: @NixOS/podman
Qt / KDE: @ttuegel
Postgres: @thoughtpolice
Co-release-manager: @worldofpeace
in case I forgot anyone: @NixOS/nixpkgs-committers
If I did forget someone, please cc them. I would like to make sure that everyone was able to voice their concerns and issues.
The text was updated successfully, but these errors were encountered: