nixVersions.stable: 2.15 -> 2.17 #247475
nixVersions.stable: 2.15 -> 2.17 #247475
Conversation
github-actions
bot
added
6.topic: nixos
|
oh cool, thanks for the notification. I'll get to writing a patch soon. |
|
briefly checked:
|
|
Harmonia bump: #247544 |
|
nix-eval-jobs bump: #247546 |
|
nix-doc fix (can remove pin after merging): #247581 |
Sorry, I was pinging you for
Okay. |
Ahh, I do maintain the nixpkgs package, but I'm not super involved in the development, but I can check if we don't get a response from @oxalica |
|
fwiw home-manager is currently having problems with nix 2.17: nix-community/home-manager#4298 |
|
harmonia does now also build on darwin: #247698 |
|
Is this waiting for something else ? |
|
I guess we don't want to merge this if this breaks commonly used tools such as home-manager, so we should await a fix on their side IMHO. |
|
also hydra needs a patch apperantly NixOS/hydra#1296 |
Merging this PR may motivate people to submit a fix. |
|
It looks like the creator of home-manager proposed a patch and just needs time to get back to a computer and test it. |
|
In both cases there are fixes in progress (in fact I use both of them personally with Nix 2.17). I don't see why we need to rush here, though. |
|
The fix was just merged in home-manager, does anyone have any other concern ? |
|
@ofborg eval |
Let's not do that anymore, please. Stable versions of Nix even on unstable are important, otherwise, this creates more work for release managers to triage what's going on, especially with respect to support channels. |
At the time I made the comment there hadn't been any activity on the linked issue for almost a week. How long are we supposed to wait? Was I expected to fix it myself to unblock this PR? |
I understand, but, like, people are on vacations (preparing for vacations, etc.), etc. Saying that it will motivate them to submit a fix is a bit rude to people in those contexts. For packages as critical as Nix (see the last upgrade for reference), it is preferable to collect much more working samples and run extensive testing, for the I am planning to write a proper policy on the subject and submit to the community. BTW, this is not specific to
I'm not sure you are expected to fix it because you cannot know all the bugs as Nix release management itself did not prove itself to be very stable and that's fine: software have bugs. But this is my responsibility and the responsibility of every Nixpkgs contributor/maintainer who care about this working for everyone, especially for complicated things like the Nix package manager, which is the core of NixOS, to ensure that we don't actively go out there and break things if we are aware they may not work. So please understand my side on this. |
|
I asked two questions, I don't think that you have answered either of them in a way that I can understand or consider to be actionable for future PRs.
|
|
You're both great contributors, so let me try to dissipate the tension.
One week could be fine in a non holiday period, but during summer or winter breaks, 3 weeks might be more appropriate for critical packages that the ecosystem depends on.
You're not expected to fix it yourself, but that does mean that the PR stays blocked until there is a real fix. The matter is complicated by the fact that 2.15 had (at least one) annoying bug that we wanted fixed by making this upgrade. |
That's because this is something to figure out, I am on vacations right now and I cannot say things that I didn't determine yet, if that does not help you for future PRs, please consider not upgrading
If you want a number, I'd say, 1 month in general is a good amount of time for critical packages, for vacations periods like summer (and especially during large scale Chaos events such as C3Camp for example). I would advise to wait 3 months after a Nix release.
No. As I explained in my previous message:
Fixing it yourself or fixing it wouldn't have unblocked this PR anyway. |
|
I'm a home manager user and I quite like it, I don't mind waiting a bit to not break it but it is an external project, I don't see how it can block updating nix here for weeks. In theory nix cuts a tag every six weeks or so and not keeping up with nix versions could come with it's own set of problems. |
Thank you for that, but Home-Manager is not the only external project here… So blocking Nix updates here for weeks is not only about giving Home-Manager the time needed to fix everything, it is to give time to all stakeholders, including the ones who are not mentioned in this PR, to pick Nix 2.17, verify that for example known regressions of the previous releases, are also retested over this version, etc. Basically, the thing is that we need a "Nix stable upgrade" checklist in nixpkgs. Not keeping up with Nix versions should not be a problem because Nixpkgs is supposed to work with Nix ≥ 2.3, so… And just to be clear: I am not opposed to bump the |
|
I don't think we moved to fast here, if anything we moved slower than usual. #188777, #204841, #211290 We can always revert and try again if necessary. #212010, #212769 2.17.0 was cut three weeks ago and added to nixpkgs the following day. This PR was opened two weeks after that and merged a week later. I think waiting half of the six week nix tag cycle to bump the default in nixpkgs is sufficient, if it isn't then perhaps people should be testing against master of the nix repo and not waiting for a new tag. |
|
@RaitoBezarius I think you're mostly right, but IMO your argument is backwards. I think Nix needs an integration test gating releases that checks what happens when the release is used in nixpkgs, and what the broad impact will be. The current cycle of:
Is not really sustainable. |
|
With that said, I acknowledge I should have waited for the My bad :) |
It was fixed. |
I agree this is backward.
I would love this and release candidates maybe.
I agree. The problem is that I am not really in a position to say what to do to Nix developers (or Nix core team), I try to communicate what I feel is needed for NixOS and inside of nixpkgs and I adjust with the reality. |
I don't understand what are you referring at. Those are initialization PRs, not stable bumps. Just to make it clear : I am completely fine and I encourage packaging the newest versions of Nix as soon as they are tagged. I am not comfortable with moving
Yes, but reverting will not fix broken systems of people who cannot upgrade anymore because they do not have the knowledge to revert their Nix version. This happens more often than you may believe and yes, people follows unstable closely and can get caught in the changes. The worse about it is that NixOS is an operating system built around Nix, you can imagine that assisting someone with a broken Nix can become much harder than a lot of community support requests we have to deal on a daily basis. So reverting is clearly not a solution here,
Who are "people" you are mentioning in "should be testing against master of the Nix repo", are you suggesting to push the maintenance burden on every consumers? That's not realistic given the nature of Nix breakages, it's not necessarily only external projects, it is sometimes Nix features in conjunction with trivial external projects, etc. This does not really make sense to me. As long as Nix, the package manager, cannot really have releases which can be trusted right away because the integration / regression testing story is still being developed (and to be clear: I know how super hard the work can be for Nix developers and I am grateful for what is there right now), we have to take into account those facts in a realistic way and provide a sensible path for all the users out there. For people who wants to live on the bleeding bleeding edge, That's my only point. 3 weeks is clearly not enough, people cannot switch immediately what they are doing to work on the newest Nix release, they cannot keep track of master all the time, etc. If we had release candidates, that would be another story, but release candidates are not a thing again, so let's not suggest more maintenance burden to people doing all their best. Let's just be patient and provide slower paths even it ends up in everyone not getting the newest shiny feature that the newest Nix release has, IMHO, this is important because then we show mindfulness to our users. |
|
Just want to add that the difficult point here is that 2.15 was already broken (ssh with control master didn't work). I think your point makes sense when 2.15 is stable and working. The hard thing is that when it's not working so well in the first place, do we risk a bug with a newer version or just leave everyone with the known bug. I think that is why this version was pushed so fast. |
Let's maybe define "broken" properly also. SSH with ControlMaster is an optimization for multiplexing SSH connections, this is not something that should be actively preventing from switching your configurations or doing things, though, I agree it create a very annoying behavior and not really fun. But it is another level of impact, it's not like, e.g. not being able to handle symlinks at all.
This is a fallacy, backporting is a thing, we do it for 23.05 because 23.05 ships 2.13 anyway. I don't want to push more maintenance burden on the Nix core team, obviously, but I try to actively track & pin "world breaking" bugs, e.g. nixos-enter, "no valid substituter" confusing error messages, symlink handling, etc. and we ask for backports for them and they get backported at some point. I do not think we can do more than this, as @lovesegfault put it, the mechanism where we move from 2.x to 2.(x + 1) to fix bugs is not really sustainable. So, here what I am reading and understanding from what you are saying, after all this discussion where I reiterated my point, is that you don't care about potentially worse bugs if you can get the bugs you care about to get fixed even if they are not necessarily on the same impact level of the potentially other bugs. So really, please no, let's not rush things, is ultimately my point. If you want something different while keeping the reasonable guarantees for stability, I'm all ears. |
They are initialization and stable bumps, don't see how they are not relevant. |
|
Good point, apologies, I am tired and I concluded on the basis that the
title was sufficient to determine the change.
Well, I will say that I don't really agree with this type of change for the
reasons explained earlier. Maybe before it was possible to have this pace
and it made sense, at least, since I am aware of more Nix breakages and
some of them are serious and can go unfixed for a very long time, I'd
really appreciate if we didn't move fast on the stable attribute.
If you need me to come forward an official policy on the matter, I can in
the next weeks.
Le ven. 18 août 2023 à 01:23, zowoq ***@***.***> a écrit :
… I don't think we moved to fast here, if anything we moved slower than
usual. #188777 <#188777>, #204841
<#204841>, #211290
<#211290>
I don't understand what are you referring at. Those are initialization
PRs, not stable bumps.
I am not comfortable with moving nixVersions.stable too quickly, what you
cited is not relevant to that point.
They are initialization and stable bumps, don't see how they are not
relevant.
—
Reply to this email directly, view it on GitHub
<#247475 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACMZRAF7LG7G6DC5GXUHHDXV2RWFANCNFSM6AAAAAA3FXTMRQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
What does "official policy" mean? An RFC? |
|
No, it would simply be an PR to CONTRIBUTING to document this aspect.
Obviously, I would put all participants of this PR in the reviewing,
advertise this policy discussion on Discourse and Matrix, wait a reasonable
amount of time for consensus building, and if that fails, we can look into
other avenues.
I am not sure RFC makes a lot of sense for that, it sets things in the
stone in a very inflexible way, Nix development practices can evolve
quickly and again, I am open to alternatives in the currently described
problem space.
Le ven. 18 août 2023 à 01:47, zowoq ***@***.***> a écrit :
… If you need me to come forward an official policy on the matter, I can in
the next weeks.
What does "official policy" mean? An RFC?
—
Reply to this email directly, view it on GitHub
<#247475 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACMZRDAWYENR5XCUML4YYTXV2USHANCNFSM6AAAAAA3FXTMRQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Description of changes
Things done
sandbox = trueset innix.conf? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)