Understanding CommitFest
CommitFest organizes proposed PostgreSQL changes so reviewers and committers can find patches that need attention. The mailing-list discussion is the source of truth. The tracker links those discussions and records their status.
Following the work
Section titled “Following the work”Start with the official CommitFest index for current cycle dates. Open a patch entry, then read its linked email thread for design decisions, newer versions, and review feedback. The activity log shows tracker changes; pgsql-hackers contains the wider development discussion.
An Open cycle accepts patch entries. During In Progress, reviewers and committers focus on that cycle. Work can also be reviewed or committed outside that period.
Reading status
Section titled “Reading status”- Needs review: feedback or review is needed.
- Waiting on Author: the author has changes to address.
- Ready for Committer: a reviewer considers the patch ready for committer attention, but further changes may be requested.
- Committed: the change has been applied to the repository. This alone does not establish availability in a released version.
A proposal is not a roadmap promise. Check the original thread and release documentation before treating it as a shipped feature.
Taking the next step
Section titled “Taking the next step”Reviewing a patch describes ways to help without knowing every part of PostgreSQL. The overview provides a dated cycle snapshot, not an automatically synchronized feed.
References
Section titled “References”- Official CommitFest app guide
- Reviewed October 28, 2026. This is an independent guide, not an official PostgreSQL website.
Follow along or get involved
Section titled “Follow along or get involved”Choose a role that fits your time: follow a proposal, test one behavior, check documentation, or review code you understand. Start with the dated queue snapshot, then follow a patch through its evidence. For hands-on feedback, use the reviewing guide.
Proposing your own change
Section titled “Proposing your own change”For a nontrivial change, discuss the problem and design on pgsql-hackers first. Send a focused patch with relevant tests and documentation, then link its thread in an open CommitFest. Follow the official submission guide; this site does not accept patch submissions.