Re: Getting a move on for 8.2 beta

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > Tom Lane wrote:
> >> Peter has made it pretty clear that he didn't care for the
> >> refactorization aspect of that patch.
>
> > Peter asked why it was done, a good answer was given, and Peter did not
> > reply.
>
> Au contraire, he's reiterated since then that he didn't like it.

The thread order was: patch, Peter comments, submitter gives reasons,
patch put in the queue, Peter comments again, I reply that the change is
not just "refactoring" but is needed based on submitters comments, and
no reply from Peter:

http://archives.postgresql.org/pgsql-patches/2006-08/msg00334.php

Without a reply from Peter, I have to assume the patch is valid.

> >> Perhaps that's because nobody but you wanted it to go in.
>
> > We got tons of people who wanted that.
>
> But no committers, else it would've got done.

True that it was of more interest to non-committers than committers,
probably because it is the committers who are going to have to remove it
when full SQL functionality is added. :-}

> There was some remark upthread about reviewers getting discouraged
> because their comments seem to fall on deaf ears. I know exactly
> what is meant by that. I'm getting tired of arguing with you about
> bad patches, because it's obvious that you put no weight on my
> objections --- and it looks like Peter has got the same problem.
> How is it that you are willing to apply submissions from newbie
> developers over the objections of core developers?

Well, as I see it, core developers have no special weight in votes,
except by their ability to influence the community by their posted
opinions. If we want core people to have a larger weight in making
decisions, I think the community should decide that. I have never heard
that stated by anyone in this group.

I think the UPDATE ... SET (val, ...) patch is illustrative. Some
committers didn't want it because it didn't add new functionality, and
because it has to be remove later when full functionality is added. But
a lot of users wanted it because it implemented part of the spec, and
because it will make porting easier. Based on how many users wanted it,
and because the patch is very localized (gram.y), I thought it should be
in 8.2. The Win32 port is an extreme case of this dichotomy ---
headache for developers, boon for the user community.

We all started as newbie patch submitters (some better than others, of
course). I think as leaders if we don't like a patch for some reason,
we have to give feedback on how the submitter can fix it, or
community-agreed reasons why the patch will never be accepted. Another
example is the FETCH/MOVE int64 patch. If there is a performance
concern, should we just ask the submitters to do testing. You mentioned
there is a way to do MOVE >2gig already, but did not supply the method.
I can't figure out what it is, and I am sure others don't know either.
If we can do it, that should be stated so we can document it and all
understand why FETCH/MOVE int64 isn't a good addition.

Basically, the people who have been around longer have to spend time to
educate patch submitters to improve. If we don't, we don't grow our
pool of experienced developers.

The fundamental problem is if someone objects to a patch, and then
someone reasonably replies to that objection, lack of a reply means to
me that the last reply was valid. I realize this places a burden on
people to discuss patches, but I see no better way to do it. I don't
think we want to go down the road where we have individuals who object
to patches, but are not required to engage in discussion about the
patch. I think many dysfunctional open source projects have this
problem.

On a personal note, Tom, I do place great weight on your opinions, and
try to adjust things to make sure you, the submitter, and everyone else
is satisified with the result.

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +