Re: Rethinking the parameter access hooks for plpgsql's benefit

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Rethinking the parameter access hooks for plpgsql's benefit
Дата
Msg-id 20150317164707.GA10492@momjian.us
обсуждение исходный текст
Ответ на 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  (Tom Lane <tgl@sss.pgh.pa.us>)
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  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-hackers
On Mon, Mar  9, 2015 at 03:06:24PM -0400, Robert Haas wrote:
> On Mon, Mar 9, 2015 at 2:33 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > As far as that goes, it has never been the case that we expected every
> > patch to go through the commitfest review process.  (If we did, our
> > response time to bugs would be probably a couple orders of magnitude
> > longer than it is.)  The way I see the policy is that committers have
> > authority to commit things that they feel are ready and that haven't
> > been objected to by other developers.  Depending on the particular
> > committer and the particular patch, feeling that a patch is "ready"
> > might or might not require that it's been through a commitfest review.
> > There is no process-based restriction on committing "ready" patches
> > except when we are in alpha/beta/RC states, which is surely months
> > away for 9.5.
> >
> > If I were looking for a formal review on this one, I would certainly
> > not expect that it would get one during the current CF.  I wasn't
> > though.
> 
> Yes, I understand.  I don't really have anything more to say about
> this.  Nothing here changes my basic feeling that we need to stop
> putting new irons in the fire and start working hard on taking irons
> out of the fire; and I think most if not all other committers are
> already doing that.  Even to the extent that they are focusing on
> their own patches rather than other people's patches, I think it is
> mostly patches that they wrote some time ago, not new things that they
> have only just written.

Sorry to be coming late to this thread.  I don't think the problem is
that Tom is working on these patches.  Rather, I think since Tom's
employer now cares more about his current work, Tom just isn't as
available to help with commitfest stuff and patch application.  

It is hard to see how the community can complain about that --- it is
like having an uncle who used to give you $20 every time you saw him,
then suddenly stops.  You would certainly be disappointed, but it is
hard to see how you have a right to complain.  Now, if Tom's work was
interrupting others' work, then there is a reasonable complaint. 

As a contrast, as someone who almost never applies things from the
commitfest, I would be even more open to criticism.  I spend my spare
time closing out unaddressed emails, but again, I have decided that is
the best use of my time, and I didn't ask anyone if they agreed.  My
assumption has always been that if activity is positive, it is up to the
individual to decide which efforts to pursue.  My employer could adjust
my activity too.

I think the larger issue is that we have to adjust to a new-normal where
Tom isn't going to be as helpful in this area.  Do we need more
committers?  Do we need to adjust the process or dates?  These are
probably the questions we should be addressing.

I think one valid criticism is that Tom should transition his
commitments to this new-normal, especially for the the Grouping Set
patch, rather than allowing things to dangle in an unknown state. 
Again, communicating expectations goes a long way in avoiding conflict.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [PATCH] Add transforms feature
Следующее
От: Tom Lane
Дата:
Сообщение: Re: ranlib bleating about dirmod.o being empty