CommitFest App
- See also: CommitFest
The CommitFest App (CFA) is a go-to location to register your patches and keep track of their progress. It is hosted in the infrastructure of the PostgreSQL project, and is thus managed by the Infrastructure team. The code for the CFA is available on the public PostgreSQL Git server, in the pgcommitfest2 repository.
Handbook
Patch tracking
Patches are tracked in the CFA, and in each of their registered CommitFests they get a state assigned. When a patch gets to a final state (i.e., Committed, Rejected, Withdrawn, Returned with Feedback) it won't move forward to new commitfests.
When a patch is created, it is initially associated to one commitfest, which is usually the next Open CommitFest, but it is also possible to register patches to Future CommitFests.
CommitFests
CommitFests are collections of patches. Each patch can be registered to several CommitFests; but generally only one of those is not already closed.
In the CFA, a commitfest can have one of these states:
- Future
- All upcoming CommitFests except the next CommitFest are in this state. New patches can be registered to this CF.
- Open
- This is the next CommitFest. New patches can be registered to this CommitFest, and patches from earlier CommitFests which are marked with Moved to next CF are moved to this CommitFest.
- In progress
- This CommitFest is currently in progress: Reviews are focused on patches registered to this CF, and we're trying to clear it of open patches.
- Closed
- The CommitFest is done; patches which were registered to this CF are either in a final state, or moved to the next CommitFest.
See also CommitFest Checklist for an operational guide for a CommitFest Manager.
Reviewing a patch
You can post reviews through the mailing list, and through the CFA directly. When you post your review through the CFA, it can automatically update the patch state, and it will send a mail for you to the mailing list.
Unless the author hasn't been actively responding and doesn't respond within a few days after a review that requests changes, it is considered common courtesy to not immediately switch the patch state to Waiting for Author when you post a review.
CommitFest per-entry information
Topic
You can register a patch under one of various topics, which improves the discoverability of each patch:
- Bug fixes
- Clients
Patches related to PSQL, libpq and the PostgreSQL wire protocol. - Code Comments
- Documentation
These patches can sometimes be found on the pgsql-docs mailing list instead of the pgsql-hackers mailing list. - Miscellaneous
- Monitoring & Control
- Performance
- Procedural Languages
Patches for the in-tree procedural languages pl/pgsql, pl/perl, and pl/python, as well as language infrastructure. - Refactoring
- Replication & Recovery
- Security
- Server Features
- SQL Commands
- System Administration
- Testing
Patches that improve the testing infrastructure, or add more coverage to our test suite.
Review states
Every CommitFest entry has a state associated with it:
- Needs Review
- The default state of a patch after creation.
- Waiting for Author
- The patch is waiting for its author to update the patch or otherwise provide a response to earlier comments.
- Ready for Committer
- The reviewers of the patch have no more comments on the patch, and the patch is ready for a Committer to review and potentially commit that patch.
- Committed
- The full patchset has been committed. Usually the Committer field will also be updated to the Committer that committed the patch.
- Returned with Feedback
- Review showed that the patch could not be committed in the current state, and there was no plan from the author to get the patch to a commitable state.
- Withdrawn
- The author decided not to move forward with this patch.
- Rejected
- This patch was not going to get accepted into PostgreSQL.
- Moved to next CF
- The patch did not get commited in this CommitFest, but has enough potential to get a chance in the next CommitFest.
Target version
When a patch adds new features, it will usually target the next major version. For bugfixes, you select the oldest supported version of PostgreSQL which has the broken behaviour.
Authors
This tracks which developers have worked on the patch.
Note that this information may not be complete: Not everyone who submits patches has a PostgreSQL Community Account, nor has everyone used the CFA (which would allow them to be registered as author).
Reviewers
This field tracks who have reviewed a patch. It is expected that people who are reviewing a patch add themselves to that list, and remove themselves when they're not going to review the patch.
This information is likely to be incomplete; not everyone who reviews a patch has registered themselves as reviewer, and inversely, not everyone who has registered themselves as reviewer has actually reviewed the patch.
Committer
Tracks which committer has committed (or is planning to commit) the patch.
Links
The user can register a Wiki link that links to a Wiki page that discusses the patch, and a Git link that points to a repository about the patch.
Emails
This section references relevant e-mail threads. You can add multiple threads if there are more than one relevant thread.
This section also allows you to add Annotations to specific mails:
History
Contains the history of the commitfest entry, i.e. who updated what information of the entry at what time.
Logging in
You can log in to the CFA with your PostgreSQL community account using the link in the top-right corner of the home page.
Integrations
CFBot
The CFBot tests patches that have been registered to the current CommitFest, and shows their status in an easy to understand format.
It tries to run CI on all active patches every few days, while prioritizing recently updated patches to decrease their cycle time. If a patch doesn't apply on the latest HEAD of the master branch, it'll keep the latest successfully applied patch's CI state intact, and add a marker to the patch's icons indicating that the patch fails to apply.
History
The CommitFest app was originally built around 2013, when it became clear that commitfest tracking on the Wiki wouldn't be sufficient and that a separate application for tracking would be required.
The requirements can still be found on the Wiki page New CommitFest App Spec.
