On 8/31/22 12:26 PM, Robert Haas wrote:
On Wed, Aug 31, 2022 at 10:20 AM Jonathan S. Katz <jk...@postgresql.org> wrote:
Andres, Robert, Tom: With this recent work, have any of your opinions
changed on including SQL/JSON in v15?

No. Nothing's been committed, and there's no time to review anything
in detail, and there was never going to be.

OK. Based on this feedback, the RMT is going to request that this is reverted.

With RMT hat on -- Andrew can you please revert the patchset?

 Nikita said he was ready
to start hacking in mid-August. That's good of him, but feature freeze
was in April. We don't start hacking on a feature 4 months after the
freeze. I'm unwilling to drop everything I'm working on to review
patches that were written in a last minute rush. Even if these patches
were more important to me than my own work, which they are not, I
couldn't possibly do a good job reviewing complex patches on top of
other complex patches in an area that I haven't studied in years. And
if I could do a good job, no doubt I'd find a bunch of problems -
whether they would be large or small, I don't know - and then that
would lead to more changes even closer to the intended release date.

I just don't understand what the RMT thinks it is doing here. When a
concern is raised about whether a feature is anywhere close to being
in a releasable state in August, "hack on it some more and then see
where we're at" seems like an obviously impractical way forward. It
seemed clear to me from the moment that Andres raised his concerns
that the only two viable strategies were (1) revert the feature and be
sad or (2) decide to ship it anyway and hope that Andres is incorrect
in thinking that it will become an embarrassment to the project. The
RMT has chosen neither of these, and in fact, really seems to want
someone else to make the decision. But that's not how it works. The
RMT concept was invented precisely to solve problems like this one,
where the patch authors don't really want to revert it but other
people think it's pretty busted. If such problems were best addressed
by waiting for a long time to see whether anything changes, we
wouldn't need an RMT. That's exactly how we used to handle these kinds
of problems, and it sucked.

This is fair feedback. However, there are a few things to consider here:

1. When Andres raised his initial concerns, the RMT did recommend to revert but did not force it. Part of the RMT charter is to try to get consensus before doing so and after we've exhausted the community process. As we moved closer, the patch others proposed some suggestions which other folks were amenable to trying.

Unfortunately, time has run out. However,

2. One of the other main goals of the RMT is to ensure the release ships "on time" which we define to be late Q3/early Q4. We factored that into the decision making process around this. We are still on time for the release.

I take responsibility for the decision making. I would be open to discuss this further around what worked / what didn't with the RMT and where we can improve in the future.

Thanks,

Jonathan

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Reply via email to