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

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Rethinking the parameter access hooks for plpgsql's benefit
Date: 2015-03-17 16:47:07
Message-ID: 20150317164707.GA10492@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)sss(dot)pgh(dot)pa(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-03-17 16:51:55 Re: ranlib bleating about dirmod.o being empty
Previous Message Robert Haas 2015-03-17 15:52:48 Re: [PATCH] Add transforms feature