From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: 2018-03 Commitfest Summary (Andres #1) |
Date: | 2018-03-02 10:06:12 |
Message-ID: | alpine.DEB.2.20.1803021050160.12500@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello Tom,
> FWIW, I share Andres' concern that pgbench is being extended far past
> what anyone has shown a need for. If we had infinite resources this
> wouldn't be a big problem, but it's eating into limited committer hours
> and I'm not really convinced that we're getting adequate return.
Another specific point about the CF patch management:
A lot of patches do not even get a review: no immediate interest or more
often no ressources currently available, patch stays put, I'm fine with
that.
Now, some happy patches actually get reviews and are switched to ready,
which shows that somebody saw enough interest in them to spend some time
to improve them.
If committers ditch these reviewed patches on weak ground (eg "I do not
need this feature so nobody should need it"), it is both in contradiction
with the fact that someone took the time to review it, and is highly
demotivating for people who do participate to the reviewing process and
contribute to hopefully improve these patches, because the reviewing time
just goes to the drain in the end even when the patch is okay.
So for me killing ready patches in the end of the process and on weak
ground can only make the process worse. The project is shooting itself in
the foot, and you cannot complain later that there is not enough
reviewers.
--
Fabien.
From | Date | Subject | |
---|---|---|---|
Next Message | Kuntal Ghosh | 2018-03-02 10:17:04 | Re: zheap: a new storage format for PostgreSQL |
Previous Message | Alexander Korotkov | 2018-03-02 10:05:16 | Re: 2018-03 Commitfest Summary (Andres #3) |