Re: Commitfest app release on Feb 17 with many improvements

From: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
To: vignesh C <vignesh21(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Jacob Brazeal <jacob(dot)brazeal(at)gmail(dot)com>
Subject: Re: Commitfest app release on Feb 17 with many improvements
Date: 2025-03-09 13:35:34
Message-ID: CAGECzQQBAbvfXHLRGSMN=_mDTF_7=JTORwFMS_CaWEPF1kmihg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, 9 Mar 2025 at 03:21, vignesh C <vignesh21(at)gmail(dot)com> wrote:
> Couple of suggestions: a) No need to show CI status as "Needs rebase,"
> "Not processed," etc., for committed patches.

Do you mean specifically for committed ones? Or just for any patch
with a "closed" status.

> b) Can we add a filter
> for "Needs rebase!"? This would help the CommitFest manager easily
> list patches that need updating.

That should be pretty easy to implement. But is that really what we
want? In the next release, sorting by "failing since" is implemented.
It sounds like that could be enough instead. i.e. do we really only
want to call out patches that need a rebase? Or also ones that have
been failing in CI for a long time?

I'm even wondering if this whole flow still makes sense. Do we really
want to send an email to the mailing list about this? And if so, why
is someone doing that manually? If people subscribe to updates for
patches that they authored, then they get these "needs rebase"
automatically. Should we maybe simply default that option to true? And
for instance send a notification automatically to all people with a
"needs rebase" CI status whenever we start a new commitfest.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message jian he 2025-03-09 13:41:49 Re: general purpose array_sort
Previous Message Michail Nikolaev 2025-03-09 12:44:00 Re: Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM?