From 27f475f27511073900e8fc45332ce5d11e6bbdf8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C3=81lvaro=20Herrera?= Date: Tue, 19 Aug 2025 11:24:45 +0200 Subject: [PATCH] Proper spelling is "Commitfest", with lowercase 'f' --- README.md | 2 +- pgcommitfest/commitfest/templates/base.html | 2 +- pgcommitfest/commitfest/templates/help.html | 18 +++++++++--------- pgcommitfest/commitfest/templates/home.html | 2 +- pgcommitfest/commitfest/views.py | 2 +- 5 files changed, 13 insertions(+), 13 deletions(-) diff --git a/README.md b/README.md index f96fdc9..0e85323 100644 --- a/README.md +++ b/README.md @@ -1,4 +1,4 @@ -# CommitFest +# Commitfest This application manages commitfests for the PostgreSQL community. diff --git a/pgcommitfest/commitfest/templates/base.html b/pgcommitfest/commitfest/templates/base.html index 8834db7..445fcc3 100644 --- a/pgcommitfest/commitfest/templates/base.html +++ b/pgcommitfest/commitfest/templates/base.html @@ -47,7 +47,7 @@
  • diff --git a/pgcommitfest/commitfest/templates/help.html b/pgcommitfest/commitfest/templates/help.html index 7a4f198..c99944a 100644 --- a/pgcommitfest/commitfest/templates/help.html +++ b/pgcommitfest/commitfest/templates/help.html @@ -1,23 +1,23 @@ {%extends "base.html"%} {%block contents%}

    - This is the "CommitFest app", the website where the PostgreSQL community tracks proposed changes to PostgreSQL. If you're familiar with GitHub, then this website fulfills a similar purpose to the list of Pull Requests (PRs) on GitHub repo. The most important difference is that the CommitFest app is not the "source of truth", instead the PostgreSQL mailinglists are. The "CommitFest app" is simply a tool to help the communtiy keep track of changes proposed on the mailinglist in an organized manner. Below are the most important concepts that you should know about when using the CommitFest app. + This is the "Commitfest app", the website where the PostgreSQL community tracks proposed changes to PostgreSQL. If you're familiar with GitHub, then this website fulfills a similar purpose to the list of Pull Requests (PRs) on GitHub repo. The most important difference is that the Commitfest app is not the "source of truth", instead the PostgreSQL mailinglists are. The "Commitfest app" is simply a tool to help the communtiy keep track of changes proposed on the mailinglist in an organized manner. Below are the most important concepts that you should know about when using the Commitfest app.

    -

    CommitFest

    +

    Commitfest

    - PostgreSQL development is organized into "CommitFests" (often abbreviated to "CF"). Each CommitFest contains a list of entries called patches (similar to PRs, see below for details). The main purpose of CommitFests are to make sure patches that people are interested in are not forgotten about, as well as running CI (aka CFBot) on these patches. Each CommitFest has a period where it is "Open", in which people can add patches to the CommitFest. This "Open" period is followed by an "In Progress" period, in which the idea is that committers and reviewers focus on reviewing and committing the patches in this "In Progress" CommitFest. At the end of the month a CommitFest gets "Closed" (and stays closed forever). Any not yet committed patches can be moved to the following "Open" CommitFest by their authors, to try again in the next cycle. Having these timebound periods has several benefits: + PostgreSQL development is organized into "Commitfests" (often abbreviated to "CF"). Each Commitfest contains a list of entries called patches (similar to PRs, see below for details). The main purpose of Commitfests are to make sure patches that people are interested in are not forgotten about, as well as running CI (aka CFBot) on these patches. Each Commitfest has a period where it is "Open", in which people can add patches to the Commitfest. This "Open" period is followed by an "In Progress" period, in which the idea is that committers and reviewers focus on reviewing and committing the patches in this "In Progress" Commitfest. At the end of the month a Commitfest gets "Closed" (and stays closed forever). Any not yet committed patches can be moved to the following "Open" Commitfest by their authors, to try again in the next cycle. Having these timebound periods has several benefits:

    1. It gives a regular cadence of development to people who like to have this.
    2. It provides a natural age-out mechanism for patches that the submitter has lost interest in.
    3. It provides an easy way for reviewers/committers to prioritize which patches to review.
    - This does not mean that patches are only committed during a CommitFest, nor that people will only respond on the mainlinglist to patches in the "In Progress" CommitFest. + This does not mean that patches are only committed during a Commitfest, nor that people will only respond on the mainlinglist to patches in the "In Progress" Commitfest.

    -

    There are 5 CommitFests per year. The first one is "In Progress" in July and starts the nine months feature development cycle of PostgreSQL. The next three are "In Progress" in September, November and January. The last CommitFest of the feature development cycle is "In Progress" in March, and ends a when the feature freeze starts. The exact date of the feature freeze depends on the year, but it's usually in early April.

    +

    There are 5 Commitfests per year. The first one is "In Progress" in July and starts the nine months feature development cycle of PostgreSQL. The next three are "In Progress" in September, November and January. The last Commitfest of the feature development cycle is "In Progress" in March, and ends a when the feature freeze starts. The exact date of the feature freeze depends on the year, but it's usually in early April.

    Patches

    - A "patch" is a bit of an overloaded term in the PostgreSQL community. Email threads on the mailing list often contain "patch files" as attachments, such a file is often referred to as a "patch". A single email can even contain multiple related "patch files", which are called a "patchset". However, in the context of a CommitFest app a "patch" usually means a "patch entry" in the CommitFest app. Such a "patch entry" is a reference to a mailinglist thread on which change to PostgreSQL has been proposed, by someone sending an email that contain one or more "patch files". The CommitFest app will automatically detect new versions of the patch files and update the "patch entry" accordingly. + A "patch" is a bit of an overloaded term in the PostgreSQL community. Email threads on the mailing list often contain "patch files" as attachments, such a file is often referred to as a "patch". A single email can even contain multiple related "patch files", which are called a "patchset". However, in the context of a Commitfest app a "patch" usually means a "patch entry" in the Commitfest app. Such a "patch entry" is a reference to a mailinglist thread on which change to PostgreSQL has been proposed, by someone sending an email that contain one or more "patch files". The Commitfest app will automatically detect new versions of the patch files and update the "patch entry" accordingly.

    There are three "Active" categories of patch status: @@ -38,7 +38,7 @@

    Drafts

    - Appart from the regular CommitFests, there is also a "Drafts" CommitFest that is used to collect patches for new features that are not yet ready for general reviewing. There are various reasons why a patch might not be ready for general reviewing but the author still wants to track it publicly in the "CommitFest app", this is usually due to the combination of one of the following reasons: + Appart from the regular Commitfests, there is also a "Drafts" Commitfest that is used to collect patches for new features that are not yet ready for general reviewing. There are various reasons why a patch might not be ready for general reviewing but the author still wants to track it publicly in the "Commitfest app", this is usually due to the combination of one of the following reasons:

    - Like regular CommitFests, a Draft CommitFest also has an "Open" period and a "Closed" state, but it has no "In Progress" period. The "Open" period for a Draft CommitFest last lasts a year. When the last CommitFest of the development cycle becomes "In Progress", the Draft CommitFest for that PostgreSQL version is closed, and a new one is immediately opened for the next PostgreSQL release. + Like regular Commitfests, a Draft Commitfest also has an "Open" period and a "Closed" state, but it has no "In Progress" period. The "Open" period for a Draft Commitfest last lasts a year. When the last Commitfest of the development cycle becomes "In Progress", the Draft Commitfest for that PostgreSQL version is closed, and a new one is immediately opened for the next PostgreSQL release.

    -

    Another difference between Draft CommitFests and regular CommitFests is that Draft CommitFests don't list resolved patches.

    +

    Another difference between Draft Commitfests and regular Commitfests is that Draft Commitfests don't list resolved patches.

    {%endblock%} diff --git a/pgcommitfest/commitfest/templates/home.html b/pgcommitfest/commitfest/templates/home.html index d5f060f..d0fbade 100644 --- a/pgcommitfest/commitfest/templates/home.html +++ b/pgcommitfest/commitfest/templates/home.html @@ -7,7 +7,7 @@

    {% endif %} -

    CommitFests

    +

    Commitfests