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?
GP is referring to the submission, in case that wasn't obvious. It's opining as to possible reasons, given the author is one of the people who had a feature reverted.
> Did someone not understand what went in?
Unlikely, from the context.
> Might someone have offloaded their thinking to some external tool?
No, according to the author, since the features predate most current LLM assisted coding.
> Did people stop caring?
I'm not sure what this means. Presumably things were reverted because people cared enough to make sure it was good quality before being released.
> Did someone not plan or design a feature in full?
An admitted possibility
> Were the timelines unrealistic?
Depending on what you mean, that may be correct according to the article, but I suspect not in the way you mean.
> Maybe with so many reverts timelines should be revised?
It sounds like there was a very large increase in load in some of the people that would commonly review during this time period, and that may or may not continue to happen to a greater or lesser degree in the future, it depends on how LLMs advance in finding bugs and if there are other large waved of bugs reported.
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.
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
Well I have a document for you to read on this very question!
_Load bearing intensifies_
Huh?
GP is referring to the submission, in case that wasn't obvious. It's opining as to possible reasons, given the author is one of the people who had a feature reverted.
> Did someone not understand what went in?
Unlikely, from the context.
> Might someone have offloaded their thinking to some external tool?
No, according to the author, since the features predate most current LLM assisted coding.
> Did people stop caring?
I'm not sure what this means. Presumably things were reverted because people cared enough to make sure it was good quality before being released.
> Did someone not plan or design a feature in full?
An admitted possibility
> Were the timelines unrealistic?
Depending on what you mean, that may be correct according to the article, but I suspect not in the way you mean.
> Maybe with so many reverts timelines should be revised?
It sounds like there was a very large increase in load in some of the people that would commonly review during this time period, and that may or may not continue to happen to a greater or lesser degree in the future, it depends on how LLMs advance in finding bugs and if there are other large waved of bugs reported.
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.
I don’t get the meaning of the article subject.
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?