Better to revert than lose a community that is invested in your ecosystem that starts looking elsewhere. I congratulate the team in acknowledging and doing the right thing. As a developer myself, I know it is a painful thing to do but important to listen to the community.
I think maintainers here listened to their gut feeling and trusted their experience.
On top of that I think this is actually great FLOSS news, knowing how many commercial products have sacrificed proper professional programming on the altar of shareholder expectations.
As an engineer, this revert post is such a positive signal of appropriate stewardship. Devs know how painful it is to build and refine something only for it to be flushed.
Congrats on the team for putting stability ahead of features for such an important codebase.
Agreed. People using Postgres aren’t there for the next feature release. We want to see development continue but not at the expense of stability. This is a very mature team and I’m glad they shared this.
> I have been on the receiving end of some of that
Multiple features?
> Maybe we just didn’t do a good enough job. Maybe the code was just not good enough. We’ll learn and improve. It’s probably some of that, and I’m mentioning it here to not give the impression that it was only the other factors that I’m going to mention.
> It could also be a coincidence. Maybe we had been on such a good roll that we attempted to tackle several features that turned out to be too hard, or at least too hard to finish in time.
All of the above seem clearly the case--not that it could be realized at the time of cutoff and not getting it cleaned up in the window.
> we, meaning all the developers affected, have had enough time to fully reflect on all this.
Title should be: The reverts will continue until quality improves. Humour is good for the clicks but also a means of deflection. I sort of feel bad saying without putting in effort contributing myself but having it merged would have been worse.
I’ve experienced this myself. I’ve had to downgrade my opinion of my own code. LLMs are great at pointing out the edge cases that you might have taken years to find. Honestly feels quite dispiriting but we move on.
Previously my main concern was with LLM's writing worse code. Now my concern is the ability to write better code than I was ever able to write before -- considering every possible potential bug and race condition and error state and what have you -- but at what cost? How much more time do you have to spend researching, designing, making decisions around every possible edge case and state?
Before, you couldn't even attempt to balance quality with speed, because you couldn't see the quality in advance. You had to wait for bug reports to come in. Now, you're confronting quality up-front in a much deeper way. Which allows for much more reliable software, but then you have to decide how much effort is worth it and how much isn't?
Maybe for many projects it's time to do a feature freeze. LLM provide a great opportunity to improve testing coverage, run automated code reviews and so on, so basically it's time to improve quality, while developers can adapt to this new LLM world and figure out the proper ways to integrate LLM to the development cycle.
Also adversaries are using abliterated LLMs right now to search for vulnerabilities, so it's important to stay ahead.
Seems like this is more about the introduction of LLM code reviews that has found edge cases that would have otherwise been missed and fixed as they appeared over years in the future. The issue is that the volume of issues has been beyond what people could do in time.
It's a play on "the beatings will continue until morale improves". You obviously can't just beat morale into people, and, knowing that, the audience should understand improvements to a bad situation will not be forthcoming. It's often used for dramatic effect as dark/silly humor when something bad happens.
A bunch of features that made it to beta turned out not to be in a state that could be made satisfactory for release time and so was reverted.
That seems to me to be the right thing to do. Unfortunate, but the right thing to do.
“[something] will continue until morale improves” is usually a sacastic dig at tone deaf and incompetent leadership (e.g, “firing will continue until morale improves”)
Not reverting would have consequences. Reverting hurts morale. It's a bad situation either way. Consider the hypothetical statement "the reverts will continue until code quality improves" while also keeping in mind that the application of popular satirical phrases can be a bit loose at times.
Yes, not only is there always improvements to existing functionality possible due to changes in improvements in general software engineering and mathematical methods beyond it or supporting new hardware features.
Generally, software engineering like other industries is evolving and there is need for different facilities. Consider graph and vector databases featuring, as well as json columns as examples of things you that are relatively recently in common use.
Better to revert than lose a community that is invested in your ecosystem that starts looking elsewhere. I congratulate the team in acknowledging and doing the right thing. As a developer myself, I know it is a painful thing to do but important to listen to the community.
I think maintainers here listened to their gut feeling and trusted their experience.
On top of that I think this is actually great FLOSS news, knowing how many commercial products have sacrificed proper professional programming on the altar of shareholder expectations.
As an engineer, this revert post is such a positive signal of appropriate stewardship. Devs know how painful it is to build and refine something only for it to be flushed.
Congrats on the team for putting stability ahead of features for such an important codebase.
Agreed. People using Postgres aren’t there for the next feature release. We want to see development continue but not at the expense of stability. This is a very mature team and I’m glad they shared this.
> I have been on the receiving end of some of that
Multiple features?
> Maybe we just didn’t do a good enough job. Maybe the code was just not good enough. We’ll learn and improve. It’s probably some of that, and I’m mentioning it here to not give the impression that it was only the other factors that I’m going to mention.
> It could also be a coincidence. Maybe we had been on such a good roll that we attempted to tackle several features that turned out to be too hard, or at least too hard to finish in time.
All of the above seem clearly the case--not that it could be realized at the time of cutoff and not getting it cleaned up in the window.
> we, meaning all the developers affected, have had enough time to fully reflect on all this.
Title should be: The reverts will continue until quality improves. Humour is good for the clicks but also a means of deflection. I sort of feel bad saying without putting in effort contributing myself but having it merged would have been worse.
I’ve experienced this myself. I’ve had to downgrade my opinion of my own code. LLMs are great at pointing out the edge cases that you might have taken years to find. Honestly feels quite dispiriting but we move on.
Same here. It's been a real eye-opener.
Previously my main concern was with LLM's writing worse code. Now my concern is the ability to write better code than I was ever able to write before -- considering every possible potential bug and race condition and error state and what have you -- but at what cost? How much more time do you have to spend researching, designing, making decisions around every possible edge case and state?
Before, you couldn't even attempt to balance quality with speed, because you couldn't see the quality in advance. You had to wait for bug reports to come in. Now, you're confronting quality up-front in a much deeper way. Which allows for much more reliable software, but then you have to decide how much effort is worth it and how much isn't?
Just need to create systems to assign priority to issues. And then systems for those systems. And...
> every possible bug and race condition and error state
a particular statement to make during the slop apocalypse
I clicked it expecting talk of llm/ai stuff but it took several paragraphs for author to get there, and to get to the point.
Not quite as bad as those recipe sites that expect you to read the rando's life story before the recipe, though.
We can thank Google for that.
> but now we also already have a few nice 80%-ready features queued up for PostgreSQL 20 that just need those remaining 80% to get done!
This is quite a nice perspective to end up on, and a little humor too.
Some of the beauty of linux that wouldn't happen in corp.
Reverts kind of suck when it's your feature getting reverted, no doubt. But for something as foundational as Postgres, the more reverts the better...
Maybe for many projects it's time to do a feature freeze. LLM provide a great opportunity to improve testing coverage, run automated code reviews and so on, so basically it's time to improve quality, while developers can adapt to this new LLM world and figure out the proper ways to integrate LLM to the development cycle.
Also adversaries are using abliterated LLMs right now to search for vulnerabilities, so it's important to stay ahead.
Seems like this is more about the introduction of LLM code reviews that has found edge cases that would have otherwise been missed and fixed as they appeared over years in the future. The issue is that the volume of issues has been beyond what people could do in time.
For those not familiar with the attention economy; the headline is clickbate and not indicative of the articles point.
This is a strong endorsement of postgres; it shows they take quality control seriously.
I don’t get the meaning of the article subject.
It's a play on "the beatings will continue until morale improves". You obviously can't just beat morale into people, and, knowing that, the audience should understand improvements to a bad situation will not be forthcoming. It's often used for dramatic effect as dark/silly humor when something bad happens.
It is a play on the old joke “The beatings will continue until morale approves.”
What, the title? "Until morale improves" is ineptly chosen, because it seems self-deprecating: https://quoteinvestigator.com/2020/07/15/morale/
Or if not the title, the general context is this: https://news.ycombinator.com/item?id=50119991
I’m not sure I like the headline.
A bunch of features that made it to beta turned out not to be in a state that could be made satisfactory for release time and so was reverted.
That seems to me to be the right thing to do. Unfortunate, but the right thing to do.
“[something] will continue until morale improves” is usually a sacastic dig at tone deaf and incompetent leadership (e.g, “firing will continue until morale improves”)
I don’t think that is fair to say here.
Not reverting would have consequences. Reverting hurts morale. It's a bad situation either way. Consider the hypothetical statement "the reverts will continue until code quality improves" while also keeping in mind that the application of popular satirical phrases can be a bit loose at times.
> as far as I can tell, this situation is not due to “vibe coding”. This code was written well before that was a possibility.
Since people refuse to read things on HN, I might as well bubble up this particular bullet point.
is it really necessary to keep using new version of postgres and to keep developing them? is it not done at this point?
Yes, not only is there always improvements to existing functionality possible due to changes in improvements in general software engineering and mathematical methods beyond it or supporting new hardware features.
Generally, software engineering like other industries is evolving and there is need for different facilities. Consider graph and vector databases featuring, as well as json columns as examples of things you that are relatively recently in common use.
> Consider graph and vector databases
sounds like a revolutionary rather than incremental change, does that get into postgres?
Yes. There's always room for improvement.