Provided that all the reverse dependencies are rebuilt and fixed accordingly, this looks fine.

+1

• There's no real contingency plan.
• There's no plan to rebuild dependent packages (or no information of it's even necessary in the case of libpq users).
• There's no information about expected compatibility for server plugins that are packaged with fedora.
• The Change owner has not responded on the mailing list at all.

For now, I have to vote -1 here, particularly when thinking about how the equivalent PostgreSQL 12 update was handled for fedora 32. I might change my vote if the Change is adapted.

Blech, ignore that... Wrong ticket and tag...

I recommend upgrading it only for rawhide.

I recently packaged pgcli for fedora.

and all dependencies of pgadmin4 are already packaged for fedora, when I have some time I will try to finish it.

-1 until my concerns on the mailing list are addressed.

-1 for the same reason..

@panovotn can you address our concerns before the next meeting?

Sadly there has been no response from the change owner here or on the mailing list.

AGREED: Give one more week for the change owners to respond (+7, 0, -0)

@panovotn pretty please ;)

@panovotn ping - we're waiting on input from you.

The proposal in the latest version leaves quite a few things unstated.
1. In "Summary: if the dependent packages are going to be rebuilt, this should be stated here too.
2. In "Scope": I would expect that trial rebuild will be done in copr, on a private build machine, or in koji scratch builds. This rebuild would include postgresq but also all dependent packages. This will allow identification of packages which fail to build.
Item "Check software that requires or depends on postgresql-server or libpq packages for incompatibilities" must be moved before "Build PostgreSQL 13 to Rawhide". Please also state how this verification will be done (mostly so that other people can participate and help and observe partial results.)
3. In "Scope": "Build PostgreSQL 13 to Rawhide": this should be done in a side tag.
Also, all the dependent packages should be built into this side tag. When everything is compiling fine, the sidetag should be merged. If some subset of packages fails to build and cannot be fixed, the sidetag can be merged.
The following items should be added to the change page: that a side tag will be used, what will be built in the side tag, what is the policy for merging.
Also, to perform those builds and possibly modify packages, either cooperation from maintainers of all dependent packages or provenpackager help will be needed. The Change must state how this will be done.
4. In "Contingency plan" — if things go south, who will do the rebuilds?

(Sorry for the formatting. If I add whitespace, pagure mangles the numbering.)

@panovotn Hey, would you like to sync about this and work on it together?

Today is the Change Checkpoint: Completion deadline (testable)

See also https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UK7PXFFRQKKAOQLE23S26X33R3O6UF4F/

Proposal: We defer this to Fedora 34 (where it would still need an approval based on the requested changes).

+1 to deferring to f34.

Reluctantly +1 to deferring to F34.

It's not ready, there's no response from the change proposal owner, and I think there's no hope that it'll get done properly right now.

+1, same reasons.

Sounds reasonable to defer, +1

APPROVED (+5, 0, -0): We defer this to Fedora 34 (where it would still need an approval based on the requested changes).

I'm closing this ticket, @panovotn please update the change proposal and submit it again for F34. My offer to help still stands.

Announced https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/ZH6L52TZMFIVVFBARGFBBYANUL5O6PKT/