Re: Why don't we have a small reserved OID range for patch revisions?
От | Tomas Vondra |
---|---|
Тема | Re: Why don't we have a small reserved OID range for patch revisions? |
Дата | |
Msg-id | d71bc22c-28b2-16e0-004c-041d11020747@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: Why don't we have a small reserved OID range for patch revisions? (Peter Geoghegan <pg@bowt.ie>) |
Список | pgsql-hackers |
On 3/1/19 12:41 AM, Peter Geoghegan wrote: > On Thu, Feb 28, 2019 at 3:09 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> The only thing that's really clear is that some senior committers don't >> want to be bothered because they don't think there's a problem here that >> justifies any additional expenditure of their time. Perhaps they are >> right, because I'd expected some comments from non-committer developers >> confirming that they see a problem, and the silence is deafening. > > I don't think that you can take that as too strong a signal. The > incentives are different for non-committers. > >> I'm inclined to commit some form of Naylor's tool improvement anyway, >> because I have use for it; I remember times when I've renumbered OIDs >> manually in patches, and it wasn't much fun. But I can't force a >> process change if there's not consensus for it among the committers. > > I think that that's a reasonable thing to do, provided there is > obvious feedback that makes it highly unlikely that the committer will > make an error at the last moment. I have a hard time coming up with a > suggestion that won't be considered annoying by at least one person, > though. > FWIW I personally would not mind if such tool / process was added. But I have a related question - do we have some sort of list of such processes that I could check? That is, a list of stuff that is expected to be done by a committer before a commit? I do recall we have [1], but perhaps we have something else. https://wiki.postgresql.org/wiki/Committing_checklist regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: