Thread

  1. New year, new commitfest app improvements

    Jelte Fennema-Nio <me@jeltef.nl> — 2026-01-06T18:46:18Z

    Hi all,
    
    There are some big changes lined up for the next release of the
    commitfest app. I'm intending to deploy these to prod in on the 20th
    of January.
    1. Remove the "topics" feature and replace it fully with the tags
    feature. For patches in most topics a matching tag will be added
    automatically (e.g. "Bug fixes" topic -> "Bugfix" tag). But there are
    a few where the conversion is lossy:
    # 'Miscellaneous' and 'Server Features' are left untagged, because they
    # are too vague.
    # 'Procedural Languages' has no direct tag equivalent, because new
    # there are tags per language. So there's no clear tag that should be
    # chosen there. Similar for 'Replication & Recovery', which also has
    # separate tags now for logical and physical replication.
    
    Full details on how stuff gets replaced can be found here[1]
    2. Commitfests now get closed in a more "friendly" manner for patch
    authors. Before authors would need to move their patches to the next
    commitfests manually. Now this is done automatically if a patch has
    had an email on the thread within 30 days AND it has had a green CI
    run in the last 21 days.
    3. For patches that did not get moved automatically by the new logic
    described above, authors will get an email that they should move or
    close these patches. (they only get this email if they have subscribed
    to author email notifications, see 5)
    4. Old commitfests and patches that are open on old commitfests now
    contain a banner warning (see attached).
    5. Change the default email notification settings to receive
    commitfest app emails for patches where you are an author. This only
    applies to new users and users who have never visited their profile
    page. Emails now include a link to the profile, so you can unsubscribe
    or subscribe to more emails.
    6. The Draft CF page won't show "Moved to other CF" entries anymore.
    (Thanks Aditya)
    7. Fix bug where not all emails would be noticed by the app (already
    deployed to prod)
    
    As always, feedback is welcome. You can see the changes live here:
    https://commitfest-test.postgresql.org/ (username and password are "pgtest")
    
    [1]: https://github.com/postgres/pgcommitfest/blob/fbd6aa760d8cc694e0a7e879ce793f51eb421915/pgcommitfest/commitfest/migrations/0016_migrate_topics_to_tags.py#L33-L51
    
  2. Re: New year, new commitfest app improvements

    Peter Geoghegan <pg@bowt.ie> — 2026-01-06T18:47:53Z

    On Tue, Jan 6, 2026 at 1:46 PM Jelte Fennema-Nio <me@jeltef.nl> wrote:
    > 2. Commitfests now get closed in a more "friendly" manner for patch
    > authors. Before authors would need to move their patches to the next
    > commitfests manually. Now this is done automatically if a patch has
    > had an email on the thread within 30 days AND it has had a green CI
    > run in the last 21 days.
    
    This sounds like a huge improvement. Thanks!
    
    -- 
    Peter Geoghegan
    
    
    
    
  3. Re: New year, new commitfest app improvements

    Jelte Fennema-Nio <me@jeltef.nl> — 2026-01-10T11:56:42Z

    On Tue, 6 Jan 2026 at 19:46, Jelte Fennema-Nio <me@jeltef.nl> wrote:
    > There are some big changes lined up for the next release of the
    > commitfest app. I'm intending to deploy these to prod in on the 20th
    > of January.
    
    After some feedback on discord and the previous release announcement
    there will be a few more changes.
    8. Commitfest tables will be more responsive on smaller screens.
    Breaking excesively long words in various columns if the table doesn't
    fit.
    9. Encourage people to choose a tag when creating a patch by:
    9a. Having a few shortcuts common ones (Bugfix, Performance, Security)
    9b. Forcing someone to confirm by clicking a checkbox if no tags selected
    9c. Make it clearer that you can scroll in the tag dropdwon by
    changing the styling a bit.
    
    > As always, feedback is welcome. You can see the changes live here:
    > https://commitfest-test.postgresql.org/ (username and password are "pgtest")
    
  4. Re: New year, new commitfest app improvements

    Andreas Karlsson <andreas@proxel.se> — 2026-01-14T01:44:28Z

    On 1/10/26 12:56 PM, Jelte Fennema-Nio wrote:
    > On Tue, 6 Jan 2026 at 19:46, Jelte Fennema-Nio <me@jeltef.nl> wrote:
    >> There are some big changes lined up for the next release of the
    >> commitfest app. I'm intending to deploy these to prod in on the 20th
    >> of January.
    > 
    > After some feedback on discord and the previous release announcement
    > there will be a few more changes.
    > 8. Commitfest tables will be more responsive on smaller screens.
    > Breaking excesively long words in various columns if the table doesn't
    > fit.
    > 9. Encourage people to choose a tag when creating a patch by:
    > 9a. Having a few shortcuts common ones (Bugfix, Performance, Security)
    > 9b. Forcing someone to confirm by clicking a checkbox if no tags selected
    > 9c. Make it clearer that you can scroll in the tag dropdwon by
    > changing the styling a bit.
    
    Thanks for being so responsive to feedback!
    
    Andreas
    
    
    
    
    
  5. Re: New year, new commitfest app improvements

    Chao Li <li.evan.chao@gmail.com> — 2026-01-14T02:39:51Z

    
    > On Jan 7, 2026, at 02:46, Jelte Fennema-Nio <me@jeltef.nl> wrote:
    > 
    > Hi all,
    > 
    > There are some big changes lined up for the next release of the
    > commitfest app. I'm intending to deploy these to prod in on the 20th
    > of January.
    > 1. Remove the "topics" feature and replace it fully with the tags
    > feature. For patches in most topics a matching tag will be added
    > automatically (e.g. "Bug fixes" topic -> "Bugfix" tag). But there are
    > a few where the conversion is lossy:
    > # 'Miscellaneous' and 'Server Features' are left untagged, because they
    > # are too vague.
    > # 'Procedural Languages' has no direct tag equivalent, because new
    > # there are tags per language. So there's no clear tag that should be
    > # chosen there. Similar for 'Replication & Recovery', which also has
    > # separate tags now for logical and physical replication.
    > 
    > Full details on how stuff gets replaced can be found here[1]
    > 2. Commitfests now get closed in a more "friendly" manner for patch
    > authors. Before authors would need to move their patches to the next
    > commitfests manually. Now this is done automatically if a patch has
    > had an email on the thread within 30 days AND it has had a green CI
    > run in the last 21 days.
    > 3. For patches that did not get moved automatically by the new logic
    > described above, authors will get an email that they should move or
    > close these patches. (they only get this email if they have subscribed
    > to author email notifications, see 5)
    > 4. Old commitfests and patches that are open on old commitfests now
    > contain a banner warning (see attached).
    > 5. Change the default email notification settings to receive
    > commitfest app emails for patches where you are an author. This only
    > applies to new users and users who have never visited their profile
    > page. Emails now include a link to the profile, so you can unsubscribe
    > or subscribe to more emails.
    > 6. The Draft CF page won't show "Moved to other CF" entries anymore.
    > (Thanks Aditya)
    > 7. Fix bug where not all emails would be noticed by the app (already
    > deployed to prod)
    > 
    > As always, feedback is welcome. You can see the changes live here:
    > https://commitfest-test.postgresql.org/ (username and password are "pgtest")
    > 
    > [1]: https://github.com/postgres/pgcommitfest/blob/fbd6aa760d8cc694e0a7e879ce793f51eb421915/pgcommitfest/commitfest/migrations/0016_migrate_topics_to_tags.py#L33-L51
    > <image.png>
    
    Hi Jelte,
    
    Thanks for the wonderful upgrade. I have a small suggestion.
    
    Suppose a patch has already created a CF entry, and a reviewer wants to suggest a code change and attaches a diff file in the thread. In that case, CI will automatically pick up the diff and run tests, which will very likely result in a CI failure. I’ve run into this situation myself; see [1].
    
    Would it make sense for CI to only pick up .patch files and ignore .diff files? Or provide some way else to indicate CI to ignore certain emails?
    
    [1] https://postgr.es/m/CANWCAZZo5rgE4+NYYES1hLN9PvonXMH=K3Z7b0TKcCBNOAjaag@mail.gmail.com
    
    Best regards,
    --
    Chao Li (Evan)
    HighGo Software Co., Ltd.
    https://www.highgo.com/
    
    
    
    
    
    
    
    
  6. Re: New year, new commitfest app improvements

    David G. Johnston <david.g.johnston@gmail.com> — 2026-01-14T02:51:48Z

    On Tuesday, January 13, 2026, Chao Li <li.evan.chao@gmail.com> wrote:
    
    >
    > Suppose a patch has already created a CF entry, and a reviewer wants to
    > suggest a code change and attaches a diff file in the thread. In that case,
    > CI will automatically pick up the diff and run tests, which will very
    > likely result in a CI failure. I’ve run into this situation myself; see [1].
    >
    > Would it make sense for CI to only pick up .patch files and ignore .diff
    > files? Or provide some way else to indicate CI to ignore certain emails?
    >
    
    Other ways exist:
    
    https://wiki.postgresql.org/wiki/Cfbot
    
    Note the section on “what is considered a patch”.
    
    There is definitely room for improved discoverability here though.
    
    David J.
    
  7. Re: New year, new commitfest app improvements

    Chao Li <li.evan.chao@gmail.com> — 2026-01-14T02:55:08Z

    
    > On Jan 14, 2026, at 10:51, David G. Johnston <david.g.johnston@gmail.com> wrote:
    > 
    > On Tuesday, January 13, 2026, Chao Li <li.evan.chao@gmail.com> wrote:
    > 
    > Suppose a patch has already created a CF entry, and a reviewer wants to suggest a code change and attaches a diff file in the thread. In that case, CI will automatically pick up the diff and run tests, which will very likely result in a CI failure. I’ve run into this situation myself; see [1].
    > 
    > Would it make sense for CI to only pick up .patch files and ignore .diff files? Or provide some way else to indicate CI to ignore certain emails?
    > 
    > Other ways exist:
    > 
    > https://wiki.postgresql.org/wiki/Cfbot
    > 
    > Note the section on “what is considered a patch”.
    > 
    > There is definitely room for improved discoverability here though.
    > 
    > David J.
    > 
    
    Good to learn. Using a “nocfbot” prefix should perfectly work.
    
    Best regards,
    --
    Chao Li (Evan)
    HighGo Software Co., Ltd.
    https://www.highgo.com/
    
    
    
    
    
    
    
    
  8. Re: New year, new commitfest app improvements

    Jelte Fennema-Nio <me@jeltef.nl> — 2026-01-23T21:29:28Z

    On Tue, 6 Jan 2026 at 19:46, Jelte Fennema-Nio <me@jeltef.nl> wrote:
    > There are some big changes lined up for the next release of the
    > commitfest app. I'm intending to deploy these to prod in on the 20th
    > of January.
    
    A few days delayed. But it's deployed now. Please report any issues
    you encounter.
    
    The 1st of Feb will be a special day. That'll be the first time that
    patches will be auto-moved and emails for unmoved patches will be sent
    to authors. So please keep an eye out for bugs/problems around that
    date too.
    
    
    
    
  9. Re: New year, new commitfest app improvements

    Pavel Luzanov <p.luzanov@postgrespro.ru> — 2026-02-03T06:16:10Z

    Hi,
    
    At first, big thanks for doing such useful changes.
    
    On 06.01.2026 21:46, Jelte Fennema-Nio wrote:
    > 1. Remove the "topics" feature and replace it fully with the tags
    > feature.
    
    Please, look at search by tags feature. I can choose several tags in 
    the  "Tag (type to search)" field,
    but it will search only patches with all these tags setted. There is no 
    possibility to find all patches for several tags.
    
    May be better to use OR instead of AND when combining tags for search?
    
    -- 
    Pavel Luzanov
    Postgres Professional:https://postgrespro.com