Thread

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

    Jelte Fennema-Nio <postgres@jeltef.nl> — 2025-06-16T12:47:46Z

    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".
    
    
    # Introducing tags
    
    This has been requested by many people. New tags can currently only be
    created through the admin interface, but they can be assigned to a
    patch by anyone. There are a bunch of tags that I added by default.
    You can also easily filter patches by a specific tag by clicking on a
    tag on a commitfest overview page. See the tags.png screenshot, or the
    staging environment:
    
    https://commitfest-test.postgresql.org/53/
    
    Big thanks to Jacob for the initial work on this feature.
    
    # 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.
    
    # 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/
    
    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.
    
    
    # Help Page
    
    There's now a help page for new users which explains how this app is
    used and what certain terminology means:
    https://commitfest-test.postgresql.org/help/
    
    # Small fixes
    
    Flonents Tselai made wiki and git links display correctly.
    
  2. Re: Huge commitfest app update upcoming: Tags, Draft CF, Help page, and automated commitfest creat/open/close

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2025-06-17T04:21:32Z

    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
    
    
    
    
  3. Re: Huge commitfest app update upcoming: Tags, Draft CF, Help page, and automated commitfest creat/open/close

    Tom Lane <tgl@sss.pgh.pa.us> — 2025-06-17T04:41:49Z

    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
    
    
    
    
  4. Re: Huge commitfest app update upcoming: Tags, Draft CF, Help page, and automated commitfest creat/open/close

    Jelte Fennema-Nio <postgres@jeltef.nl> — 2025-06-17T07:05:04Z

    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.
    
    
    
    
  5. Re: Huge commitfest app update upcoming: Tags, Draft CF, Help page, and automated commitfest creat/open/close

    Jelte Fennema-Nio <postgres@jeltef.nl> — 2025-06-17T08:05:25Z

    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.
    
  6. Re: Huge commitfest app update upcoming: Tags, Draft CF, Help page, and automated commitfest creat/open/close

    Peter Eisentraut <peter@eisentraut.org> — 2025-06-18T03:58:16Z

    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. ;-)
    
    
    
    
  7. Re: Huge commitfest app update upcoming: Tags, Draft CF, Help page, and automated commitfest creat/open/close

    Jelte Fennema-Nio <postgres@jeltef.nl> — 2025-06-18T07:11:15Z

    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).
    
    
    
    
  8. Re: Huge commitfest app update upcoming: Tags, Draft CF, Help page, and automated commitfest creat/open/close

    Peter Eisentraut <peter@eisentraut.org> — 2025-06-20T13:21:40Z

    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.
    
    
    
    
    
  9. Re: Huge commitfest app update upcoming: Tags, Draft CF, Help page, and automated commitfest creat/open/close

    David G. Johnston <david.g.johnston@gmail.com> — 2025-06-20T14:41:42Z

    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.
    
  10. Re: Huge commitfest app update upcoming: Tags, Draft CF, Help page, and automated commitfest creat/open/close

    Peter Eisentraut <peter@eisentraut.org> — 2025-06-22T13:47:27Z

    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.
    
    
    
    
    
  11. Re: Huge commitfest app update upcoming: Tags, Draft CF, Help page, and automated commitfest creat/open/close

    David G. Johnston <david.g.johnston@gmail.com> — 2025-06-22T14:21:36Z

    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.
    
  12. Re: Huge commitfest app update upcoming: Tags, Draft CF, Help page, and automated commitfest creat/open/close

    Vik Fearing <vik@postgresfriends.org> — 2025-06-22T16:23:05Z

    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
    
  13. Re: Huge commitfest app update upcoming: Tags, Draft CF, Help page, and automated commitfest creat/open/close

    Jelte Fennema-Nio <postgres@jeltef.nl> — 2025-06-22T20:50:23Z

    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.
    
    
    
    
  14. Re: Huge commitfest app update upcoming: Tags, Draft CF, Help page, and automated commitfest creat/open/close

    Jelte Fennema-Nio <postgres@jeltef.nl> — 2025-06-22T20:55:55Z

    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?
    
    
    
    
  15. Re: Huge commitfest app update upcoming: Tags, Draft CF, Help page, and automated commitfest creat/open/close

    Tatsuo Ishii <ishii@postgresql.org> — 2025-06-23T01:37:26Z

    > 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
    
    
    
    
  16. Re: Huge commitfest app update upcoming: Tags, Draft CF, Help page, and automated commitfest creat/open/close

    Jelte Fennema-Nio <postgres@jeltef.nl> — 2025-06-23T06:46:56Z

    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).
    
    
    
    
  17. Re: Huge commitfest app update upcoming: Tags, Draft CF, Help page, and automated commitfest creat/open/close

    Tatsuo Ishii <ishii@postgresql.org> — 2025-06-23T06:52:09Z

    > 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
    
    
    
    
  18. Re: Huge commitfest app update upcoming: Tags, Draft CF, Help page, and automated commitfest creat/open/close

    David G. Johnston <david.g.johnston@gmail.com> — 2025-06-25T00:01:29Z

    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.
    
  19. Re: Huge commitfest app update upcoming: Tags, Draft CF, Help page, and automated commitfest creat/open/close

    Aleksander Alekseev <aleksander@timescale.com> — 2025-06-25T17:56:11Z

    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
    
    
    
    
  20. Re: Huge commitfest app update upcoming: Tags, Draft CF, Help page, and automated commitfest creat/open/close

    David G. Johnston <david.g.johnston@gmail.com> — 2025-06-25T18:23:41Z

    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.
    
  21. Re: Huge commitfest app update upcoming: Tags, Draft CF, Help page, and automated commitfest creat/open/close

    Aleksander Alekseev <aleksander@timescale.com> — 2025-06-25T18:28:52Z

    Hi,
    
    > 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.
    
    Found it. It was moved to the "Your personal dashboard" page.
    Previously I used the CF page thus I couldn't find it.
    
    Many thanks.
    
    -- 
    Best regards,
    Aleksander Alekseev
    
    
    
    
  22. Re: Huge commitfest app update upcoming: Tags, Draft CF, Help page, and automated commitfest creat/open/close

    Jelte Fennema-Nio <postgres@jeltef.nl> — 2025-06-25T19:59:23Z

    On Wed, 25 Jun 2025 at 20:29, Aleksander Alekseev
    <aleksander@timescale.com> wrote:
    >
    > Hi,
    >
    > > 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.
    >
    > Found it. It was moved to the "Your personal dashboard" page.
    > Previously I used the CF page thus I couldn't find it.
    
    Ugh... Turns out it was a bug, there definitely should be a "New
    patch" button on both the 19-1 and on the Drafts page. And there
    was... but only if you were logged in as a staff user.
    
    
    I had changed a field name to from "isopen" to "is_open" and forgot to
    change the usage in that template. Very annoying that django templates
    not complaining about missing attributes...
    
    
    
    
  23. Re: Huge commitfest app update upcoming: Tags, Draft CF, Help page, and automated commitfest creat/open/close

    Aleksander Alekseev <aleksander@timescale.com> — 2025-06-25T21:50:33Z

    Hi,
    
    > Ugh... Turns out it was a bug, there definitely should be a "New
    > patch" button on both the 19-1 and on the Drafts page. And there
    > was... but only if you were logged in as a staff user.
    
    There is now a "New patch" button on the CF entry page. Many thanks!
    
    > I had changed a field name to from "isopen" to "is_open" and forgot to
    > change the usage in that template. Very annoying that django templates
    > not complaining about missing attributes...
    
    Time to rewrite CF application in Haskell and Yesod? :D (Not
    realistic, I know...)
    
    -- 
    Best regards,
    Aleksander Alekseev
    
    
    
    
  24. Re: Huge commitfest app update upcoming: Tags, Draft CF, Help page, and automated commitfest creat/open/close

    vignesh C <vignesh21@gmail.com> — 2025-07-02T03:39:52Z

    On Thu, 26 Jun 2025 at 03:21, Aleksander Alekseev
    <aleksander@timescale.com> wrote:
    >
    > Hi,
    >
    > > Ugh... Turns out it was a bug, there definitely should be a "New
    > > patch" button on both the 19-1 and on the Drafts page. And there
    > > was... but only if you were logged in as a staff user.
    >
    > There is now a "New patch" button on the CF entry page. Many thanks!
    
    I felt we can remove the "New patch" button from the Current CF page
    as the commitfest is in progress, shouldn't the new patches be added
    to PG19-2 commitfest.
    
    Regards,
    Vignesh
    
    
    
    
  25. Re: Huge commitfest app update upcoming: Tags, Draft CF, Help page, and automated commitfest creat/open/close

    Aleksander Alekseev <aleksander@timescale.com> — 2025-07-02T10:02:19Z

    Hi,
    
    > > > Ugh... Turns out it was a bug, there definitely should be a "New
    > > > patch" button on both the 19-1 and on the Drafts page. And there
    > > > was... but only if you were logged in as a staff user.
    > >
    > > There is now a "New patch" button on the CF entry page. Many thanks!
    >
    > I felt we can remove the "New patch" button from the Current CF page
    > as the commitfest is in progress, shouldn't the new patches be added
    > to PG19-2 commitfest.
    
    It seems like cfbot.cputube.org started to miss a *few* entries since
    CF started. Does it have anything to do with the CF application
    update?
    
    -- 
    Best regards,
    Aleksander Alekseev
    
    
    
    
  26. Re: Huge commitfest app update upcoming: Tags, Draft CF, Help page, and automated commitfest creat/open/close

    Jelte Fennema-Nio <postgres@jeltef.nl> — 2025-07-02T16:20:05Z

    On Wed, 2 Jul 2025 at 12:02, Aleksander Alekseev
    <aleksander@timescale.com> wrote:
    > It seems like cfbot.cputube.org started to miss a *few* entries since
    > CF started. Does it have anything to do with the CF application
    > update?
    
    That's fixed now.
    
    
    
    
  27. Re: Huge commitfest app update upcoming: Tags, Draft CF, Help page, and automated commitfest creat/open/close

    Aleksander Alekseev <aleksander@tigerdata.com> — 2025-07-14T21:27:40Z

    Hi,
    
    > > It seems like cfbot.cputube.org started to miss a *few* entries since
    > > CF started. Does it have anything to do with the CF application
    > > update?
    >
    > That's fixed now.
    
    Many thanks. I also noticed that cfbot doesn't show entries from the
    *upcoming* commitfest. I believe it did before and according to the CF
    application CI checks are executed for these patches, just not shown
    on cfbot. Is it intentional?
    
    
    
    
  28. Re: Huge commitfest app update upcoming: Tags, Draft CF, Help page, and automated commitfest creat/open/close

    Jelte Fennema-Nio <postgres@jeltef.nl> — 2025-07-15T08:16:53Z

    On Mon, 14 Jul 2025 at 23:27, Aleksander Alekseev
    <aleksander@tigerdata.com> wrote:
    > Many thanks. I also noticed that cfbot doesn't show entries from the
    > *upcoming* commitfest. I believe it did before and according to the CF
    > application CI checks are executed for these patches, just not shown
    > on cfbot. Is it intentional?
    
    You can click the "Next Commitfest" button at the top [1]. I'm pretty
    sure this has always worked like this.
    
    [1]: https://cfbot.cputube.org/next.html