On Sun, Oct 3, 2021 at 12:15 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > An important note to make here is that we don't have any explicit > mechanism for saying "sorry, this patch is perhaps useful but it > seems that nobody is going to take an interest in it". Closing > such a patch as "rejected" seems harsh, but R-W-F isn't very > appropriate either if the patch never got any real review. > Perhaps we should create a new closure state?
We don't reject patches, except in very rare cases where the whole concept is wildly unreasonable, or when the patch author decides to mark their own patch rejected. In other words, we only reject patches where the formal status of being rejected hardly matters at all. I have to wonder what the point of the status of "rejected" really is. Ambiguity about what the best way forward is seems to be the thing that kills patches -- it is seldom mistakes or design problems. They can usually be corrected easily. Sometimes the ambiguity is very broad, other times it's just one aspect of the design (e.g., the planner aspects). I'd rather go in the opposite direction here: merge "Rejected" and "Returned with Feedback" into a single "Patch Returned" category (without adding a third category). The odds of a CF entry that gets marked R-W-F eventually being committed is, in general, totally unclear, or seems to be. I myself have zero faith that that status alone predicts anything, good or bad. I think that under-specifying why a patch has been returned like this would actually be *more* informative. Less experienced contributors wouldn't have to waste their time looking for some signal, when in fact there is little more than noise. > Index Skip Scan 16 > Last substantive discussion 2021-05, currently passing cfbot > > Seems possibly useful, but we're not making progress. This feature is definitely useful. My pet theory is that it hasn't made more progress because it requires expertise in two fairly distinct areas of the system. There is a lot of B-Tree stuff here, which is clearly my thing. But I know that I personally am much less likely to work on a patch that requires significant changes to the planner. Maybe this is a coordination problem. -- Peter Geoghegan
