Huge commitfest app update upcoming: Tags, Draft CF, Help page, and automated commitfest creat/open/close

On Mon, Jun 16, 2025 at 6:48 PM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:

The new PG19 development cycle is starting soon. So that seemed like a
good excuse to make some big improvements to the commitfest app. My
plan is to deploy these changes on the 30th of June. So that we can
start the new cycle fresh with these changes. As always feedback on
these changes is very welcome. The below will contain some links to
the staging environment both username and password for the http auth
are "pgtest".

Huge thanks for the huge changes.

Coinciding tooling changes with a milestone in tool usage has
potential to disrupt both. But in this case, the things seem to be
working in the staging environment. So I hope the start of PG19-1
commitfest will be smoother and a better experience.

Some comments below.

# Draft CF

There's now an additional Draft CF. People can move patches there as a
way of not forgetting about them. CFBot will rerun these patches less
frequently (exact behaviour TBD). Draft CFs are never "In Progress"
and are open until the final CF of the release cycle becomes "In
Progress". So PG19-Drafts will close on February 28th 2026, and at the
same moment PG20-Drafts will be opened.

Big thanks to David G Johnston for the initial work on this feature,
and early review/feedback on all my changes to it.

This is interesting. I liked the idea of making Draft CF link part of
the landing page. People can find draft patches easily in case they
want to try those out and labelling them as "Draft" will set the
expectations right.

# Automated commitfest open/close/create

Right now people manually have to open/close/create commitfests at our
regular cadence. This now actually encodes this cadence in the app
itself. A new open commitfest is automatically created when needed. As
well as commitfests automatically getting started or closed. The only
commitfest that's not fully automated is the last one of the cycle,
since that ends when the feature freeze starts (and the feature freeze
isn't always the same date). To handle that the RMT (or anyone with
access) should change the enddate of the final commitfest in the admin
interface to the new date. That will need to happen before March 31st.

A *bikesheddable* change here is the names that the newly created
commitfests get automatically. Given we now have a Drafts commitfest,
it seemed reasonable to align the naming of the regular commitfests
with that. The draft commitfest will be called:

- PG19-Drafts

And our already well-known commitfests for PG19 will be called as follows:

- PG19-1 (previously 2025-07)
- PG19-2 (previously 2025-09)
- PG19-3 (previously 2025-11)
- PG19-4 (previously 2026-01)
- PG19-Final (previously 2026-03)

The dates will be the same, the name will simply not be of the
{year}-{month} format anymore. The actual dates will still be easily
visible though. So the intent is that no-one loses information, but
instead people will gain information because it's clear what Postgres
version a commitfest is about.

# New homepage

The homepage is revamped. It now shows only "In Progress", "Open",
"Draft" and "Previous" commitfests and it also shows names & dates for
"Next open CF" and "Final CF of the release cycle". See homepage.png
screenshot for details or go to
https://commitfest-test.postgresql.org/

I like this as well. I feel "In Progress" doesn't convey that the
column contains the dates when the CFs are active. It can be easily
confused with "In progress" CF. How about just "Dates" or "Duration"?

The full list of commitfests is still available at:
https://commitfest-test.postgresql.org/commitfest_history/ This page
is linked to at the bottom most link on the homepage.

All patches in the current commitfest
All patches in the open commitfest

Are those two needed anymore since the CF links are already available?

Create a new commitfest entry - if we are creating the CFs
automatically, is this link that useful? And it could be a button/link
in the Commitfest section itself just before or after the table of
relevant commitfests.

--
Best Wishes,
Ashutosh Bapat

Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> writes:

On Mon, Jun 16, 2025 at 6:48 PM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:

The new PG19 development cycle is starting soon. So that seemed like a
good excuse to make some big improvements to the commitfest app. My
plan is to deploy these changes on the 30th of June.

Coinciding tooling changes with a milestone in tool usage has
potential to disrupt both.

Yeah. I think it might be smarter to push these changes a bit earlier
than the 30th, maybe by a week? Better to file down any rough edges
before we start the new CF.

regards, tom lane

On Tue, 17 Jun 2025 at 06:41, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Yeah. I think it might be smarter to push these changes a bit earlier
than the 30th, maybe by a week? Better to file down any rough edges
before we start the new CF.

Sounds good to me. Unless there are big objections, I'll deploy this
on the 23rd.

On Tue, 17 Jun 2025 at 06:21, Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:

I like this as well. I feel "In Progress" doesn't convey that the
column contains the dates when the CFs are active. It can be easily
confused with "In progress" CF. How about just "Dates" or "Duration"?

I decided to overhaul the table a bit more than you suggested. I added
a "When Open" and "When In Progress" columns now. See attached
screenshot.

The full list of commitfests is still available at:
https://commitfest-test.postgresql.org/commitfest_history/ This page
is linked to at the bottom most link on the homepage.

All patches in the current commitfest
All patches in the open commitfest

Are those two needed anymore since the CF links are already available?

The nice feature of these links is that they are stable, so you can
bookmark them. i.e. they don't contain a specific commitfest number.

Create a new commitfest entry - if we are creating the CFs
automatically, is this link that useful? And it could be a button/link
in the Commitfest section itself just before or after the table of
relevant commitfests.

It's not about creating a new commitfest, but it's about creating a
new *entry*. In a future commitfest app update I'd like to move all
these links to a titlebar, instead of having them on the homepage.

On 16.06.25 14:47, Jelte Fennema-Nio wrote:

And our already well-known commitfests for PG19 will be called as follows:

- PG19-1 (previously 2025-07)
- PG19-2 (previously 2025-09)
- PG19-3 (previously 2025-11)
- PG19-4 (previously 2026-01)
- PG19-Final (previously 2026-03)

The dates will be the same, the name will simply not be of the
{year}-{month} format anymore. The actual dates will still be easily
visible though. So the intent is that no-one loses information, but
instead people will gain information because it's clear what Postgres
version a commitfest is about.

Can you explain the motivation for this change a bit more?

I think I kind of like the calendar hints that the previous naming
gives. You can estimate how long ago something was or how long you
still have to finish or prepare something. The release number isn't
that meaningful, and the numbering withing the release less so.

Also, I wonder if this scheme would cause confusion about the question,
when and where am I allowed to submit patches for PG20? Would that go
into, say, PG19-4 or into PG20-Drafts?

Actually, even as I'm typing this message, I'm mentally confusing PG19-3
with "March". The number "3" just has these connotations of aaah,
better get it done. ;-)

On Wed, 18 Jun 2025 at 05:58, Peter Eisentraut <peter@eisentraut.org> wrote:

Can you explain the motivation for this change a bit more?

A few main reasons (from important to unimportant):
1. For new/irregular contributors the old names were really not
obvious IMO. It took me 3+ years to get the mental association with
March, that that was the final one for the release.
2. Looking up a historic patch from the mailinglist in the CF app,
should now give you a good idea what PG version it got in. (e.g. Oh,
AIO support got committed in PG18-Final)
3. The March commitfest is actually not just March, it ends at the
feature freeze. Which again is not obvious for many irregular users.
4. For the Draft CFs we needed a new naming scheme, and this aligns
nicely with it.
5. It's a little bit shorter

I think I kind of like the calendar hints that the previous naming
gives.

To be clear, this new naming scheme is definitely up for discussion.
It's easily changeable/revertible/tunable. However, unless there's an
overwhelming negative response to this email thread about this, I
think it's worth trying out. If it's not to people's liking after
trying it out for a while (e.g. after one or two commitfests), then we
can still easily change the names back to the old scheme (even of
already created/closed commitfests).

You can estimate how long ago something was or how long you
still have to finish or prepare something. The release number isn't
that meaningful, and the numbering withing the release less so.

To be clear, I did not intend to make this harder to find out.. The
dates are still visible on the homepage, just next to the name instead
of in the name. I realized now, they are indeed missing in a few other
places. Specifically the title of a commitfest page, and the patch
page. I fixed those now, if you find other places please let me know.

Also, I wonder if this scheme would cause confusion about the question,
when and where am I allowed to submit patches for PG20? Would that go
into, say, PG19-4 or into PG20-Drafts?

I don't think this will be a problem in practice. PG20-Drafts and
PG20-1 will open at the same time: 1st of March. Before that time
people will only be able to submit to PG19-Drafts and PG19-X (with X
depending on the time of year).

Actually, even as I'm typing this message, I'm mentally confusing PG19-3
with "March". The number "3" just has these connotations of aaah,
better get it done. ;-)

Yeah, I totally get that, there's definitely some trained stress about
the number 3 for me too. But as explained in my number one reason for
the change, new users don't have that stress yet. I think Final has
those stressful connotations more naturally (and I expect getting used
to Final shouldn't be too hard for you either).

On 16.06.25 14:47, Jelte Fennema-Nio wrote:

# Draft CF

There's now an additional Draft CF. People can move patches there as a
way of not forgetting about them. CFBot will rerun these patches less
frequently (exact behaviour TBD). Draft CFs are never "In Progress"
and are open until the final CF of the release cycle becomes "In
Progress". So PG19-Drafts will close on February 28th 2026, and at the
same moment PG20-Drafts will be opened.

Can we clarify the expectations around this?

In some early discussions, I had heard this being talked about as a
"parking lot". You can put patches there so that they get CI runs, but
no one else is really expected to pay attention to them. Makes sense.

But many patches that are routinely submitted to normal commit fests are
really drafts, in that they are in an early phase of development but
still need feedback.

I sense there could be some confusion whether such draft patches should
go into the regular commit fest or the draft commit fest, and then also
when they should move between them.

On Friday, June 20, 2025, Peter Eisentraut <peter@eisentraut.org> wrote:

On 16.06.25 14:47, Jelte Fennema-Nio wrote:

# Draft CF

There's now an additional Draft CF. People can move patches there as a
way of not forgetting about them. CFBot will rerun these patches less
frequently (exact behaviour TBD). Draft CFs are never "In Progress"
and are open until the final CF of the release cycle becomes "In
Progress". So PG19-Drafts will close on February 28th 2026, and at the
same moment PG20-Drafts will be opened.

Can we clarify the expectations around this?

In some early discussions, I had heard this being talked about as a
"parking lot". You can put patches there so that they get CI runs, but no
one else is really expected to pay attention to them. Makes sense.

But many patches that are routinely submitted to normal commit fests are
really drafts, in that they are in an early phase of development but still
need feedback.

I sense there could be some confusion whether such draft patches should go
into the regular commit fest or the draft commit fest, and then also when
they should move between them.

Draft CF patches with “Needs Review” are looking for feedback from others
or otherwise aid in development for a patch that isn’t ready to be
committed even if said review turns up nothing or is otherwise fully
resolved. Patches in Drafts are never marked Ready to Commit, they get
moved to Open first.

It will be nice if people spend time providing reviews/feedback to patches
in Drafts when requested.

It’s purely the author’s judgement on the readiness of the patch, whether
absent our policy they would mark it ready to commit or not. If they
believe it is it should be moved to open, if no, it should remain in
drafts. This is mostly like what happens today but with a clear
delineation between reviews to help and reviews to approve commit-ability.

Otherwise, it’s a place where author patches can sit without having to be
bumped to the next cf every other month and where an author patch can be
ignored by everyone else not authoring it.

David J.

On 20.06.25 16:41, David G. Johnston wrote:

I sense there could be some confusion whether such draft patches
should go into the regular commit fest or the draft commit fest, and
then also when they should move between them.

Draft CF patches with “Needs Review” are looking for feedback from
others or otherwise aid in development for a patch that isn’t ready to
be committed even if said review turns up nothing or is otherwise fully
resolved.  Patches in Drafts are never marked Ready to Commit, they get
moved to Open first.

It will be nice if people spend time providing reviews/feedback to
patches in Drafts when requested.

It’s purely the author’s judgement on the readiness of the patch,
whether absent our policy they would mark it ready to commit or not.  If
they believe it is it should be moved to open, if no, it should remain
in drafts.  This is mostly like what happens today but with a clear
delineation between reviews to help and reviews to approve commit-ability.

Otherwise, it’s a place where author patches can sit without having to
be bumped to the next cf every other month and where an author patch can
be ignored by everyone else not authoring it.

I don't know about this. This could become an ongoing source of
confusion, without any clear benefit. Either the draft and the "real"
commitfest are going to be indistinguishable, because they are just two
places to look for stuff to review in various phases of maturity. Or
the draft commitfest is just not going to get any attention, which will
be annoying for those who put things there hoping to get attention.

On Sunday, June 22, 2025, Peter Eisentraut <peter@eisentraut.org> wrote:

On 20.06.25 16:41, David G. Johnston wrote:

I sense there could be some confusion whether such draft patches
should go into the regular commit fest or the draft commit fest, and
then also when they should move between them.

Draft CF patches with “Needs Review” are looking for feedback from others
or otherwise aid in development for a patch that isn’t ready to be
committed even if said review turns up nothing or is otherwise fully
resolved. Patches in Drafts are never marked Ready to Commit, they get
moved to Open first.

It will be nice if people spend time providing reviews/feedback to
patches in Drafts when requested.

It’s purely the author’s judgement on the readiness of the patch, whether
absent our policy they would mark it ready to commit or not. If they
believe it is it should be moved to open, if no, it should remain in
drafts. This is mostly like what happens today but with a clear
delineation between reviews to help and reviews to approve commit-ability.

Otherwise, it’s a place where author patches can sit without having to be
bumped to the next cf every other month and where an author patch can be
ignored by everyone else not authoring it.

I don't know about this. This could become an ongoing source of
confusion, without any clear benefit. Either the draft and the "real"
commitfest are going to be indistinguishable, because they are just two
places to look for stuff to review in various phases of maturity. Or the
draft commitfest is just not going to get any attention, which will be
annoying for those who put things there hoping to get attention.

Yes, more experienced people have to want to help people who can’t just get
a patch ready to commit on their own. As opposed to only reviewing things
they expect to perform the formality of the review to make it ready to
commit. The tooling help distinguish those cases if used properly. But
people have to choose to do the things it encourages/enables.

If one performs a review of a non-draft and it isn’t close to ready,
encourage the author to move it into drafts as part of a teaching moment of
how their expectations of done-ness and yours differ.

We aren’t going to get 100% accuracy here but it’s is better information
that intends to address the complaint that what we had was not fit for
purpose because the information it provided was insufficient. Tags get
even more granular while this provides high-level draft/non-draft
delineation where drafts don’t have to keep being shuffled around. Review
Need still needs review no matter where it is. That doesn’t change.

David J.

On 22/06/2025 16:21, David G. Johnston wrote:

On Sunday, June 22, 2025, Peter Eisentraut <peter@eisentraut.org> wrote:

On 20.06.25 16:41, David G. Johnston wrote:

    I sense there could be some confusion whether such draft
patches
    should go into the regular commit fest or the draft commit
fest, and
    then also when they should move between them.

Draft CF patches with “Needs Review” are looking for feedback
from others or otherwise aid in development for a patch that
isn’t ready to be committed even if said review turns up
nothing or is otherwise fully resolved.  Patches in Drafts are
never marked Ready to Commit, they get moved to Open first.

It will be nice if people spend time providing
reviews/feedback to patches in Drafts when requested.

It’s purely the author’s judgement on the readiness of the
patch, whether absent our policy they would mark it ready to
commit or not.  If they believe it is it should be moved to
open, if no, it should remain in drafts.  This is mostly like
what happens today but with a clear delineation between
reviews to help and reviews to approve commit-ability.

Otherwise, it’s a place where author patches can sit without
having to be bumped to the next cf every other month and where
an author patch can be ignored by everyone else not authoring it.

I don't know about this.  This could become an ongoing source of
confusion, without any clear benefit.  Either the draft and the
"real" commitfest are going to be indistinguishable, because they
are just two places to look for stuff to review in various phases
of maturity.  Or the draft commitfest is just not going to get any
attention, which will be annoying for those who put things there
hoping to get attention.

Yes, more experienced people have to want to help people who can’t
just get a patch ready to commit on their own.  As opposed to only
reviewing things they expect to perform the formality of the review to
make it ready to commit.  The tooling help distinguish those cases if
used properly.  But people have to choose to do the things it
encourages/enables.

If one performs a review of a non-draft and it isn’t close to ready,
encourage the author to move it into drafts as part of a teaching
moment of how their expectations of done-ness and yours differ.

We aren’t going to get 100% accuracy here but it’s is better
information that intends to address the complaint that what we had was
not fit for purpose because the information it provided was
insufficient.  Tags get even more granular while this provides
high-level draft/non-draft delineation where drafts don’t have to keep
being shuffled around.  Review Need still needs review no matter where
it is.  That doesn’t change.

+1

--

Vik Fearing

On Mon, 16 Jun 2025 at 14:47, Jelte Fennema-Nio <postgres@jeltef.nl> wrote:

The new PG19 development cycle is starting soon. So that seemed like a
good excuse to make some big improvements to the commitfest app.

These changes have now been deployed to production. Please report any
problems, either as a reply or as a github issue.

On Sun, 22 Jun 2025 at 15:47, Peter Eisentraut <peter@eisentraut.org> wrote:

I don't know about this. This could become an ongoing source of
confusion, without any clear benefit. Either the draft and the "real"
commitfest are going to be indistinguishable, because they are just two
places to look for stuff to review in various phases of maturity. Or
the draft commitfest is just not going to get any attention, which will
be annoying for those who put things there hoping to get attention.

I think I agree with this. We decided to go for the "Draft" name to
align with GitHub terminology. But if our usage of it is different
than how people often use the feature in GitHub it seems better to
have a different name.

How about we rename "Drafts" to "Parking Lot" (as originally proposed
for the name) and add a "Draft" tag as an option to handle the "this
is not finished, but I'd love some feedback anyway" situation?

Sounds good to me. Unless there are big objections, I'll deploy this
on the 23rd.

Sorry if this has been already reported or fixed. I tried "Personal
Dashboard".

https://commitfest.postgresql.org/me/

And I found "Author" column is shown as "+4207-35" which does not seem
to be an author name. Likewise followings columns seem to show
inappropriate contents.

Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp

On Mon, 23 Jun 2025 at 03:37, Tatsuo Ishii <ishii@postgresql.org> wrote:

And I found "Author" column is shown as "+4207-35" which does not seem
to be an author name. Likewise followings columns seem to show
inappropriate contents.

Thanks for the report. That's fixed now (it was missing a header
column for the new Tags column).

On Mon, 23 Jun 2025 at 03:37, Tatsuo Ishii <ishii@postgresql.org> wrote:

And I found "Author" column is shown as "+4207-35" which does not seem
to be an author name. Likewise followings columns seem to show
inappropriate contents.

Thanks for the report. That's fixed now (it was missing a header
column for the new Tags column).

Thanks for the prompt response. I confirmed the fix.

Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp

On Mon, Jun 16, 2025 at 5:47 AM Jelte Fennema-Nio <postgres@jeltef.nl>
wrote:

The new PG19 development cycle is starting soon. So that seemed like a
good excuse to make some big improvements to the commitfest app. My
plan is to deploy these changes on the 30th of June. So that we can
start the new cycle fresh with these changes. As always feedback on
these changes is very welcome. The below will contain some links to
the staging environment both username and password for the http auth
are "pgtest".

Been using this a bit today:

Due to using "Open" for Drafts the tag colors for Pg19-Drafts and PG19-1
are identical. They need to be different.

When creating a new patch it should either be placed in Drafts first, and
then moved if appropriate, or the user should choose (and be given an
explanation of the decision factors behind that choice) during creation.

The "Help -" tag coloring probably should indicate some kind of blocker, so
a hot color like red/orange/yellow. Presently it is green, which for many
is an "All good" color.

David J.

Hi,

The new PG19 development cycle is starting soon. So that seemed like a
good excuse to make some big improvements to the commitfest app.

These changes have now been deployed to production. Please report any
problems, either as a reply or as a github issue.

Firstly, many thanks for working on this.

I don't see a button that would allow me to add a patch to PG19-1
(2025-07-01 - 2025-07-31). I tried to log out and log in but it didn't
change anything. Is it a bug or do I miss something?

--
Best regards,
Aleksander Alekseev

On Wed, Jun 25, 2025 at 10:56 AM Aleksander Alekseev <
aleksander@timescale.com> wrote:

Hi,

The new PG19 development cycle is starting soon. So that seemed like a
good excuse to make some big improvements to the commitfest app.

These changes have now been deployed to production. Please report any
problems, either as a reply or as a github issue.

Firstly, many thanks for working on this.

I don't see a button that would allow me to add a patch to PG19-1
(2025-07-01 - 2025-07-31). I tried to log out and log in but it didn't
change anything. Is it a bug or do I miss something?

Fourth link down from the top of the link section - "Create a new
commitfest entry"

Adds it to 19-1; need to move it to Drafts if that is where it belongs.

David J.