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.
Did someone not understand what went in? Might someone have offloaded their thinking to some external tool? Did people stop caring? Did someone not plan or design a feature in full? Were the timelines unrealistic? Maybe with so many reverts timelines should be revised?
The blog post mentions rising standards of quality enabled by AI-assisted code review, and that reverted code predates the era of AI. Even very competently managed codebases are not above mistakes, especially when held to as high of a standard as this.
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.
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.
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...
But why were they reverted?
Did someone not understand what went in? Might someone have offloaded their thinking to some external tool? Did people stop caring? Did someone not plan or design a feature in full? Were the timelines unrealistic? Maybe with so many reverts timelines should be revised?
I wonder
The blog post mentions rising standards of quality enabled by AI-assisted code review, and that reverted code predates the era of AI. Even very competently managed codebases are not above mistakes, especially when held to as high of a standard as this.
1 reply →
Well I have a document for you to read on this very question!
3 replies →
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.
What, the title? "Until morale improves" is ineptly chosen, because it seems self-deprecating: https://news.ycombinator.com/item?id=50119991
It is a play on the old joke “The beatings will continue until morale approves.”
This is a strong endorsement of postgres; it shows they take quality control seriously.
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.
Yes. There's always room for improvement.
[flagged]