On Mon, Sep 21, 2020 at 9:41 AM Alvaro Herrera <alvhe...@2ndquadrant.com> 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.
As Michael said, it had been inactive for three *months*. I don't think there's a big problem here. I think that the redesign of the CommitFest application encourages carrying things along from CF to CF forever, instead of getting rid of things that aren't wanted or aren't making any progress. That's work we don't need. There ought to be a way to mark a patch RwF when nothing's happen that lets it be revived later if and when someone gets around to resubmitting, but I think that's not possible now. Then, too, since we have email integration now, maybe we ought to do that automatically if the thread isn't getting updated and the patch is setting there waiting on author. It's a real waste of CFM time to chase down and kick out obviously-inactive patches, and if the CFM is going to get flack for it then that's even worse. Like, do we have 170 patches now because we have more activity than a few years ago, or just because we've become more reluctant to boot things? I don't know, but to the extent it's from unwillingness to boot things, I think that's bad. Discouraging contributors is not good, but wasting CFM and commiter time is also bad. You've got to draw a line someplace or you'll go nuts. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company