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  (Bruce Momjian <bruce@momjian.us>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: parallel mode and parallel contexts
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: INSERT ... ON CONFLICT IGNORE (and UPDATE) 3.0