Re: Command statistics system (cmdstats) - Mailing list pgsql-hackers

On Mon, Sep 21, 2020 at 10:41:46AM -0300, Alvaro Herrera wrote:
> "A couple of weeks" of inactivity is not sufficient, in my view, to boot
> a patch out of the commitfest process.  Whenever the patch is
> resurrected, it will be a new entry which won't have the history that it
> had accumulated in the long time since it was created -- which biases
> it against other new patches.

Any of the patches that have been marked as RwF last week have been
waiting on author since at least the end of the commit fest of July,
with zero actions taken on them.  In my experience, this points
strongly to the fact that these are unlikely going to be worked on
actively in a short time frame.

> I'm not really arguing about this one patch only, but more generally
> about the process you're following.  The problem is that you as CFM are
> imposing your personal priorities on the whole process by punting
> patches ahead of time -- you are saying that nobody else should be
> looking at updating this patch because it is now closed.  It seems fair
> to do so at the end of the commitfest, but it does not seem fair to do
> it when it's still mid-cycle.

I think that this remark is a bit unfair.  When it comes to any patch
in the commit fest, and I have managed a couple of them over the
years, I have tried to keep a neutral view for all of them, meaning
that I only let the numbers speak by themselves, mostly:
- When has a patch lastly been updated.
- What's the current state in the CF app  If the patch had no reviews
and still in "Needs review", simply switch it to "waiting on author".
If the patch has been waiting on author for more than two weeks, it
would get marked as RwF at the end of the CF.  There are also cases
where the status of the patch is incorrect, mostly that a patch
waiting on author because of a review was not updated as such in the
CF app.  In this case, and in the middle of a CF, this would get get
marked as Rwf, but the author would get a reminder of that.

Any of the patches that have been discarded by me last week were
waiting in the stack for much, much, longer than that, and I think
that it does not help reviewers and committers in keeping this stuff
longer than necessary because this mainly bloats the CF app in a
non-necessary way, hiding patches that should deserve more attention.
Some of those patches have been left idle for half a year.

Another point that I'd like to make here is that my intention was to
lift the curve here (a term quite fashionable this year particularly,
isn't it?), due to the high number of patches to handle in a single
CF, and the shortage of hands actually doing this kind of work.

Then, let's be clear about one last thing.  If at *any* moment people
here feel that at least the state of *one* patch of this CF has been
changed based on some of my "personal" priority views, I will
immediately stop any action as CFM and resign from it.  So, if that's
the case, please feel free to speak up here or on any of the threads
related to those patches.

> Putting also in perspective the history that the patch had prior to your
> unfairly closing it, there was a lot of effort in getting it reviewed to
> a good state and updated by the author --  yet a single unsubstantiated
> comment, without itself a lot of effort on the reviewer's part, that
> "maybe it has a perf drawback" is sufficient to get it booted?  It
> doesn't seem appropriate.

I agree on the fact that not being able to recreate a new CF entry
that keeps the history of an old one, with all the past threads or
annotations, could be helpful in some cases.  Now, I have seen as well
cases where a patch got around for so long with a very long thread
made things confusing, and that people also like starting a new thread
with a summary of the past state as a first message to attempt
clarifying things.  So both have advantages.
--
Michael