From: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: commitfest.postgresql.org is no longer fit for purpose |
Date: | 2024-05-24 19:17:15 |
Message-ID: | e256b693-89d3-4026-a6b0-23ca8f3857e3@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 5/24/24 19:09, Tom Lane wrote:
> Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> writes:
>> On 5/20/24 16:16, Robert Haas wrote:
>>> On Sun, May 19, 2024 at 3:18 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>> * Before starting this thread, Robert did a lot of very valuable
>>>> review of some individual patches. I think what prompted him to
>>>> start the thread was the realization that he'd only made a small
>>>> dent in the problem. Maybe we could divide and conquer: get a
>>>> dozen-or-so senior contributors to split up the list of pending
>>>> patches and then look at each one with an eye to what needs to
>>>> happen to move it along (*not* to commit it right away, although
>>>> in some cases maybe that's the thing to do). It'd be great if
>>>> that could happen just before each commitfest, but that's probably
>>>> not practical with the current patch volume. What I'm thinking
>>>> for the moment is to try to make that happen once a year or so.
>
>>> I like this idea.
>
>> Me too. Do you think it'd happen throughout the whole year, or at some
>> particular moment?
>
> I was imagining a focused community effort spanning a few days to
> a week. It seems more likely to actually happen if we attack it
> that way than if it's spread out as something people will do when
> they get around to it. Of course the downside is finding a week
> when everybody is available.
>
>> We used to do a "triage" at the FOSDEM PGDay meeting, but that used to
>> be more of an ad hoc thing to use the remaining time, with only a small
>> subset of people. But that seems pretty late in the dev cycle, I guess
>> we'd want it to happen early, perhaps during the first CF?
>
> Yeah, early in the cycle seems more useful, although the summer might
> be the worst time for peoples' availability.
>
I think meeting all these conditions - a week early in the cycle, but
not in the summer, when everyone can focus on this - will be difficult.
If we give up on everyone doing it at the same time, summer would be a
good time to do this - it's early in the cycle, and it tends to be a
quieter period (customers are on vacation too, so fewer incidents).
So maybe it'd be better to just set some deadline by which this needs to
be done, and make sure every pending patch has someone expected to look
at it? IMHO we're not in position to assign stuff to people, so I guess
people would just volunteer anyway - the CF app might track this.
It's not entirely clear to me if this would effectively mean doing a
regular review of those patches, or something less time consuming.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-05-24 19:29:39 | Re: Add SPLIT PARTITION/MERGE PARTITIONS commands |
Previous Message | Fabrízio de Royes Mello | 2024-05-24 18:59:08 | Re: Add minimal C example and SQL registration example for custom table access methods. |