Re: Rethinking the parameter access hooks for plpgsql's benefit
От | Peter Geoghegan |
---|---|
Тема | Re: Rethinking the parameter access hooks for plpgsql's benefit |
Дата | |
Msg-id | CAM3SWZQ=wrw304wwV2Lp9FRx2U9tacYtyejiv_9WYkP9k_FwPA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Rethinking the parameter access hooks for plpgsql's benefit (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Rethinking the parameter access hooks for plpgsql's
benefit
|
Список | pgsql-hackers |
On Tue, Mar 17, 2015 at 3:50 PM, Robert Haas <robertmhaas@gmail.com> wrote: >> In any case, I reject the notion that the CF process has anything to >> do with that decision. The point of the CF submission deadline is >> that we promise to consider every submission made before the deadline. >> It is not to forbid committers from taking up items that arrived later, >> if they feel motivated to. > > So this is really what it boils down to: you evidently think there is > no problem with new feature patches showing up a month or two after > the last CommitFest has started. I do. It distracts everyone from > focusing on the patches that were submitted earlier, so that they > don't get dealt with. If the patch comes from a committer, it's > actually worse, because patches from non-committers can be safely > ignored until a committer expresses interest in them, but if the patch > is from a committer who obviously intend to push it along, you'd > better drop what you're doing and object pretty fast, or it'll already > be in the tree before you get around to it. I think it's perfectly > appropriate for the project to have a feature submission deadline, I > think having such a deadline is important to both the timeliness and > the quality of our releases, and I think most people here understand > that deadline to be the start of the last CF. I agree. New feature patches being committed that were originally posted significantly after that deadline are not against the letter of the law. However, that does not make them consistent with its spirit. It's a value judgement as to whether or not any individual case violates this spirit, but in my judgement this work does. I don't think it's outrageous that it was suggested, but that's how I feel about it. I don't see a very compelling cost/benefit ratio for the community as a whole. I, as a non-committer, have proposed that the rules be bent once or twice in the past, and those suggestions were rejected without exception, even though I imagined that there was a compelling cost/benefit ratio. I thought that was fine. I always assumed that I had the same right to suggest something as a committer. The only fundamental difference was that I had to convince a committer that my assessment was correct, rather than simply avoiding having the suggestion be vetoed. I'd need to do both. Clearly my previous understanding of this was questionable, to say the least. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: