FFS, I get if upstream changes and some options don’t apply any more, but just breaking it because we improved our internal handling? This has to stop!
We have to start standing up for this and calling this type of behavior out more:
7 Likes
Few more points on why I think the linked PR is especially bad:
- It did “sneak” in a sweeping refactoring - including outright removal of options - under the guise of a “security enhancement”, with a
severity: securitylabel, without that being security related in any way. - A member of the NixOS security team approved and merged it, which means that
- either they didn’t give it a second look which would totally invert the security concern
- or they did review it and decided that the security concern trumped every other matter, not realizing that the breaking change was totally unrelated to the security enhancement
- or they did just not care about downstream while reviewing and being “fine with the changes”, effectively being fine with the
securitylabel being abused.
- This in turn severly weakens the weight that security arguments will have in any future discussion, so please do better also by the security team!
Yes, I realize that calling out [what’s @ElSuisse s user name here?], @pacien and @minijackson isn’t the most polite thing to do, but you know what? Polite would have been to not force me to waste a half-day of my precious development time, to deal with this mess.
I truly aplologize that NixOS’ culture has done wrong by you, apparently failing to teach the merits of production stability, and that we don’t break stuff without very good reason and while taking every possible precaution to make it easy to transition.
But all of you are also Members, so the other maintainers are trusting you implicitly, and we are right to hold each other to a higher standard. Please do better!
4 Likes
I mean, if you don’t want this kind of thing to happen, maybe run stable? You talk about “production stability” and at the same time run the branch literally named “UNSTABLE”.
I can understand (and have done so myself) people getting upset and complain about breaking changes on the stable branch. Now I can also kinda understand the frustration after having to spend half a day to fix something after a change that you think was unnecessary (though wouldn’t a rollback have been better if it was THAT inconvenient to change right now?). But I believe that going to calling out people by name is a bit over the top here. Maybe sleep a night over it and consider if you went a bit overboard here.
21 Likes
And what happens in 6 months when unstable becomes the new stable, and old stable gets abandoned?
That argument is dangerously close to being abusive. Just because you also got hurt, doesn’t mean it has to be that way.
Also, please take the time to review all of my arguments. My complaint is not that something broke, it is that:
- it got broken without a good reason
- it got broken, mixed in and under the guise of a totally unrelated “
security” fix - it got broken without deprecation notice or other warning
- they even speculated about backporting to stable(!!!)
Any of these points would already be irresponsible on their own.
4 Likes
The module was refactored to add multi-instance support to a module that would benefit from it. Breaking changes are allowed on master.
- they even speculated about backporting to stable(!!!)
Irrelevant, it wasn’t backported. Simply suggesting that is not a crime.
9 Likes
Your complaints are largely valid, a security fix should not be mixed with a refactor, precisely so that non-breaking backports are possible.
That said, demanding things stay in a forever-unbroken state is less valid unless this was communicated beforehand. Unstable exists so that people can refactor things, and users get good update notes, pre-warning and a migration period. If you run unstable, you risk those not being produced by the time the change hits you.
It’s also entirely unreasonable to blame someone for something that they decided against doing.
The problem isn’t your complaint, it’s primarily your tone; the contributors in question have a right not to be abused. Give them the benefit of the doubt, politely ask why things were done this way, see if something can be done to prevent future mistakes. Stay constructive. I know this isn’t always easy in dev, this is the exact kind of thing e.g. Linus Torvalds went through anger management training for.
35 Likes
I don’t think calling out someone on bad behavior is abusive. It might not be pleasant, but calling out behaviors can never be abusive in the same way as calling out appearance, origin or other inherent attributes are. Behaviors can change, and criticism is the tool to make them.
I get that “asking questions” is the more polite way to do that, and if they weren’t Members, I’d probably have done that. That would also have easily added another day to my time necessary to spend.
It’s also entirely unreasonable to blame someone for something that they decided against doing. The problem isn’t your complaint, it’s primarily your tone
Please don’t tone police me. I’m aware that many people may balk at me being that direct. But I decided against being more polite in this case. You know why? I got the same types of responses, when I tried asking about this issue in a much more polite tone a year ago: No expectation of stability on unstable; Can’t expect everything to stay the same forever;
I’m over it. I can and will expect better from my fellow maintainers!
6 Likes
Then it appears in the Release notes that you hopefully read before updating your critical production systems and then you handle the issue. And if it’s a really really critical production system, you do the update on a test system first.
Lots of people speculate about lots of different things. Point is, it wasn’t backported to stable. If it was, I would fully understand and support your complaint.
5 Likes
Then it appears in the Release notes that you hopefully read before updating your critical production systems and then you handle the issue. And if it’s a really really critical production system, you do the update on a test system first.
OK, so for 24.11 I’ll just change all the options around, make a quick changelog entry and then tell everybody to eat it, because breakage is allowed on unstable, and besides, forcing everyone to review their whole config also has security benefits … (?) … profit!
1 Like
You are being direct and quite a bit obnoxious right here. It is possible (though not easy) to both be direct, and avoid needlessly annoying everyone in process by inflammatory language.
18 Likes
I am wonder which case is this:
- there are well understood and written down nixpkgs backwards comparability guarantees, and the PR in question violates them.
- there are well understood and written down nixpkgs backwards comparability guarantees, the PR is in line with them, and is an evidence that we need to adjust the guidelines.
- there are no agreed upon guidelines, so it’s a case-by-case decision by each individual maintainer, and the PR is an evidence that we need some guidelines.
6 Likes
You can try, but I doubt they will let you. Are we really making “slippery slope” arguments here now? The PR had a clear motivation and seems to solve issues that people had. You didn’t have these issues, you don’t agree with the reasoning, fine, but your personal sensitivities or whether the fixed issue affects you in the first place doesn’t decide if something is “willy-nilly” or a necessary.
3 Likes
I’m actually arguing for a fourth option:
- there are understood guidelines, the PR is in line with them, and there is no need to adjust the guidelines, I just want everyone to do better
I think rule-lawyering can only hurt us (see all of the “you don’t get to complain about something that’s allowed” in this thread, and frankly every other thread about this), when we can just as easily strive to do better.
We’ll never be able to make a ruleset comprehensive enough to absolve us from trying to do better. It doesn’t work with inclusion, and it doesn’t work with coding standards.
1 Like
Instead of discussing the chain of causes that led here and what we can do to prevent this in the future, this thread pretty much immediately goes into putting people on blast and then defending the practice of doing that as hard as possible. I don’t really think shaming people for breaking things is going to be the solution to anything, though, unless the problem you want to solve is that people actually want to work on NixOS and you’d prefer if they didn’t.
9 Likes
Erm, you do have to define “better”. You can’t just wish for everyone to behave the way you think they should, that’s not how collaboration in large projects functions.
At the very least the community should agree on guidelines about what constitutes a good reason to break backwards compatibility on unstable, if the current state is considered unreasonable. This doesn’t have to be a legal contract, but you can’t just guess.
As it stands, people don’t agree with your opinion on what the threshold should be, which does not indicate that their opinions are inferior, but simply that they disagree.
I don’t think people would oppose discussion on whether there should be tighter control on backwards compatibility on unstable, but… You can’t just unanimously decide what changes are acceptable by yourself.
3 Likes
The problem here is that “better” is a value function that’s different for different people. In particular, compatibility is often in tension with security and desire for clean code. While yes, of course you can’t have guidelines which solve the tradeoff unambiguously in every specific case, it is useful to have shared and written down general principles, which can help steer decisions here.
Right now, you are arguing from a position of “that’s like, my opinion man”, which is weaker than “hey, this is how we all have agreed to do things here”.
That being said, even in the presence of documented guidelines, steering the informal culture by individual discussions of specifics is very valuable! But my gut feeling is that such nudges are more effective if they are driven by positive energy.
14 Likes
unless the problem you want to solve is that people actually want to work on NixOS and you’d prefer if they didn’t.
Are you conflating “contributing” with “maintaining” here?
As I said from the start: I’m holding my fellow maintainers to a higher standard. I’m always going way out of my way to be courteous when interacting with contributors.
Erm, you do have to define “better”. You can’t just wish for everyone to behave the way you think they should … you can’t just guess .
I absolutely can!
But I’m also happy to define “better”: It’s taking great care to avoid breakage, whenever possible.
Right now, you are arguing from a position of “that’s like, my opinion man”, which is weaker than “hey, this is how we all have agreed to do things here”.
Well … in a way, I consider that approach to actually be stronger: I don’t waste any time with dressing up my opinion as an interpretation of policy. If policy needs to change to suit my opinion, fine. If not enough support arises for my opinion, at least I don’t waste anybody’s time with an appeal to authority (except my own, which seems plenty triggering to a few folks, apparently). It actually increases your freedom to agree or disagree with me as you see fit.
That being said, even in the presence of documented guidelines, steering the informal culture by individual discussions of specifics is very valuable! But my gut feeling is that such nudges are more effective if they are driven by positive energy.
Agreed, as detailed. And thanks for showing this by example.
1 Like
Just imagine being courteous to everybody. Unbelievable!
3 Likes
Are we really making “slippery slope” arguments here now?
Here, @LeSuisse makes the argument, that since the security fix would have implied some minor breakage (as I pointed out, wouldn’t even have affected most users), they decided to include the whole refactoring - a much larger break - … to be done with it?
Just so I know what you’re defending here, what would you call that type of argument?
I think if anything we’re being too conservative in making changes to unstable.
One of the great advantages of our declarative approach is that you will discover incompatibilities before actually rolling out changes to your machine, so you have a choice to adapt to incompatibilities immediately or stick with a previous version (and schedule your upgrade for later).
Especially on unstable, ‘mistakes will be made’, and then you take the opportunity to collaborate on how to make the experience better for people who upgrade later. I appreciate you did that somewhat by proposing having both a services.fcgiwrap and a services.fcgiwraps. I must admit I’m not fond of that idea, though, since it increases the maintenance burden - I would rather see better warnings/release notes so upgrading to the new structure becomes easier to do.
About holding fellow-members to high standards: I don’t want people to sugar-coat or tiptoe around their position, but I do want people to help make this a pleasant project to participate in, and yes, that does include keeping your frustration in check somewhat - as a fellow-member you also have a responsibility in that regard.
8 Likes