Thread: release management team statement on patch reverts

release management team statement on patch reverts

From
Robert Haas
Date:
The PostgreSQL 9.6 release management team has determined that there
is insufficient consensus at this time to revert any of the patches
mentioned in http://www.postgresql.org/message-id/CA+TgmoYOWTtBQEL+Bv=w93bvUjbXSUw3uGnp+R29dduZ==8K0Q@mail.gmail.com
because, with the exception of "snapshot too old", none of those
patches have attracted more than a single vote to revert.  While
"snapshot too old" has attracted three votes to revert (Tom, Bruce,
Andres), one of those was on the grounds of not liking the feature i
general rather than any specific problem with the implementation (Tom)
and another gave no reason at all (Bruce).  When originally proposed,
there was clear consensus that the feature was useful, so any revert
should be on the grounds that the current implementation is flawed.

The release management team notes that, while all of these patches
have multiple reported issues, it currently appears that all of those
issues are being worked on by authors of those patches.  Many of those
issues already have proposed patches, and those patches should be
given due consideration before proceeding with a revert.

The release management team encourages senior hackers and committers
to study these patches and the defects reported against them in detail
and to offer further opinions on whether fixing or reverting is more
appropriate in each case.  The technical reasons for those judgements
should be set forth in detail so that everyone can understand why the
patch is or is not a major risk to the stability of PostgreSQL 9.6.

-- 
Robert Haas
PostgreSQL 9.6 Release Management Team



Re: release management team statement on patch reverts

From
Tom Lane
Date:
Robert Haas <robertmhaas@gmail.com> writes:
> The PostgreSQL 9.6 release management team has determined that there
> is insufficient consensus at this time to revert any of the patches
> mentioned in http://www.postgresql.org/message-id/CA+TgmoYOWTtBQEL+Bv=w93bvUjbXSUw3uGnp+R29dduZ==8K0Q@mail.gmail.com
> because, with the exception of "snapshot too old", none of those
> patches have attracted more than a single vote to revert.  While
> "snapshot too old" has attracted three votes to revert (Tom, Bruce,
> Andres), one of those was on the grounds of not liking the feature i
> general rather than any specific problem with the implementation (Tom)
> and another gave no reason at all (Bruce).  When originally proposed,
> there was clear consensus that the feature was useful, so any revert
> should be on the grounds that the current implementation is flawed.

... which, indeed, is precisely what Andres is asserting, no?  I do
not understand your conclusion.

If the threshold is "more than one vote to revert", I'm sure that can
be arranged.  For the most part I think people have assumed that if
one senior hacker complains about something, it's not really necessary
for other people to duplicate that person's review effort.  We don't
have a surplus of manpower available for such things, and I believe
most of us are going flat out right now anyway trying to get ready
for beta.  Duplicate reviews are hard to come by.
        regards, tom lane



Re: release management team statement on patch reverts

From
"Joshua D. Drake"
Date:
On 05/04/2016 12:51 PM, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> The PostgreSQL 9.6 release management team has determined that there
>> is insufficient consensus at this time to revert any of the patches
>> mentioned in
http://www.postgresql.org/message-id/CA+TgmoYOWTtBQEL+Bv=w93bvUjbXSUw3uGnp+R29dduZ==8K0Q@mail.gmail.com
>> because, with the exception of "snapshot too old", none of those
>> patches have attracted more than a single vote to revert.  While
>> "snapshot too old" has attracted three votes to revert (Tom, Bruce,
>> Andres), one of those was on the grounds of not liking the feature i
>> general rather than any specific problem with the implementation (Tom)
>> and another gave no reason at all (Bruce).  When originally proposed,
>> there was clear consensus that the feature was useful, so any revert
>> should be on the grounds that the current implementation is flawed.
>
> ... which, indeed, is precisely what Andres is asserting, no?  I do
> not understand your conclusion.
>
> If the threshold is "more than one vote to revert", I'm sure that can
> be arranged.  For the most part I think people have assumed that if
> one senior hacker complains about something, it's not really necessary
> for other people to duplicate that person's review effort.  We don't
> have a surplus of manpower available for such things, and I believe
> most of us are going flat out right now anyway trying to get ready
> for beta.  Duplicate reviews are hard to come by.

Just my .02, pretty sure the majority of the community says, "TGL just 
sent -1, argument over." That may or may not be a good thing but his 
experience and depth of knowledge of our code base pretty much seals it 
for most of us.

Sincerely,

JD

-- 
Command Prompt, Inc.                  http://the.postgres.company/                        +1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.



Re: release management team statement on patch reverts

From
Robert Haas
Date:
On Wed, May 4, 2016 at 3:51 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> The PostgreSQL 9.6 release management team has determined that there
>> is insufficient consensus at this time to revert any of the patches
>> mentioned in
http://www.postgresql.org/message-id/CA+TgmoYOWTtBQEL+Bv=w93bvUjbXSUw3uGnp+R29dduZ==8K0Q@mail.gmail.com
>> because, with the exception of "snapshot too old", none of those
>> patches have attracted more than a single vote to revert.  While
>> "snapshot too old" has attracted three votes to revert (Tom, Bruce,
>> Andres), one of those was on the grounds of not liking the feature i
>> general rather than any specific problem with the implementation (Tom)
>> and another gave no reason at all (Bruce).  When originally proposed,
>> there was clear consensus that the feature was useful, so any revert
>> should be on the grounds that the current implementation is flawed.
>
> ... which, indeed, is precisely what Andres is asserting, no?  I do
> not understand your conclusion.

Yes, and "asserting" is the right word, per my complaints in the first
paragraph of:

http://www.postgresql.org/message-id/CA+TgmoYXb8mX9qTMZ-yTAaeL4svRvQE32YT66CWoN3x7KBxp2Q@mail.gmail.com

> If the threshold is "more than one vote to revert", I'm sure that can
> be arranged.  For the most part I think people have assumed that if
> one senior hacker complains about something, it's not really necessary
> for other people to duplicate that person's review effort.  We don't
> have a surplus of manpower available for such things, and I believe
> most of us are going flat out right now anyway trying to get ready
> for beta.  Duplicate reviews are hard to come by.

I don't think that >1 person saying something necessarily constitutes
a consensus, but 1 person saying something and 1 other person offering
a counter-argument sure doesn't.  I have not yet read
http://www.postgresql.org/message-id/16807.1462388069@sss.pgh.pa.us
and that may shed a different light on the situation, but as of a few
minutes ago the arguments thus far advanced for reverting any of the
patches I mentioned in
http://www.postgresql.org/message-id/CA+TgmoYOWTtBQEL+Bv=w93bvUjbXSUw3uGnp+R29dduZ==8K0Q@mail.gmail.com
had convinced zero of three RMT members.

I believe that it is, and has long been, the community's general
policy that in doubtful cases, the discretion of the relevant
committer prevails.  This may or may not be the best policy, but it is
usually how we operate.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



Re: release management team statement on patch reverts

From
Robert Haas
Date:
On Wed, May 4, 2016 at 4:00 PM, Joshua D. Drake <jd@commandprompt.com> wrote:
> Just my .02, pretty sure the majority of the community says, "TGL just sent
> -1, argument over." That may or may not be a good thing but his experience
> and depth of knowledge of our code base pretty much seals it for most of us.

Sure, but Tom is also human, and sometimes doesn't like things that
other people still think are good ideas.  Tom questioned whether
parallel query was really a good idea, and also Hot Standby.  If we'd
given up on having those features when Tom opened his mouth, we'd be
worse off today.

That is not to say that we shouldn't defer to Tom's judgement in many
cases.  And I do.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



Re: release management team statement on patch reverts

From
"Joshua D. Drake"
Date:
On 05/04/2016 01:03 PM, Robert Haas wrote:
> On Wed, May 4, 2016 at 4:00 PM, Joshua D. Drake <jd@commandprompt.com> wrote:
>> Just my .02, pretty sure the majority of the community says, "TGL just sent
>> -1, argument over." That may or may not be a good thing but his experience
>> and depth of knowledge of our code base pretty much seals it for most of us.
>
> Sure, but Tom is also human, and sometimes doesn't like things that
> other people still think are good ideas.  Tom questioned whether
> parallel query was really a good idea, and also Hot Standby.  If we'd

Like you said, he is human ;)

> given up on having those features when Tom opened his mouth, we'd be
> worse off today.
>
> That is not to say that we shouldn't defer to Tom's judgement in many
> cases.  And I do.

Right and I agree with that. I was just saying that in this particular 
case, I think a lot of people were just accepting on the single -1.

JD

>


-- 
Command Prompt, Inc.                  http://the.postgres.company/                        +1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.



Re: release management team statement on patch reverts

From
Andres Freund
Date:
Hi,

On 2016-05-04 16:01:18 -0400, Robert Haas wrote:
> On Wed, May 4, 2016 at 3:51 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Robert Haas <robertmhaas@gmail.com> writes:
> >> The PostgreSQL 9.6 release management team has determined that there
> >> is insufficient consensus at this time to revert any of the patches
> >> mentioned in
http://www.postgresql.org/message-id/CA+TgmoYOWTtBQEL+Bv=w93bvUjbXSUw3uGnp+R29dduZ==8K0Q@mail.gmail.com
> >> because, with the exception of "snapshot too old", none of those
> >> patches have attracted more than a single vote to revert.  While
> >> "snapshot too old" has attracted three votes to revert (Tom, Bruce,
> >> Andres), one of those was on the grounds of not liking the feature i
> >> general rather than any specific problem with the implementation (Tom)
> >> and another gave no reason at all (Bruce).  When originally proposed,
> >> there was clear consensus that the feature was useful, so any revert
> >> should be on the grounds that the current implementation is flawed.
> >
> > ... which, indeed, is precisely what Andres is asserting, no?  I do
> > not understand your conclusion.
>
> Yes, and "asserting" is the right word, per my complaints in the first
> paragraph of:
>
> http://www.postgresql.org/message-id/CA+TgmoYXb8mX9qTMZ-yTAaeL4svRvQE32YT66CWoN3x7KBxp2Q@mail.gmail.com

Uh. I *did* previously explain what I think was wrong (including quoting
the salient code), and I wasn't asked for further details. And the issue
is pretty obvious. I've the growing feeling that people simply aren't
bothering to actually look at what's been pointed out.

I also want to reiterate that I didn't immediately call for a revert,
initially - before recognizing the architectural issue - I offered to
write code to address the regressions due to the spinlocks.

Greetings,

Andres



Re: release management team statement on patch reverts

From
Bruce Momjian
Date:
On Wed, May  4, 2016 at 01:50:39PM -0700, Andres Freund wrote:
> I also want to reiterate that I didn't immediately call for a revert,
> initially - before recognizing the architectural issue - I offered to
> write code to address the regressions due to the spinlocks.

I was the same case --- I didn't call for the patch to be reverted, but
rather considered for reversion:
  "I also strongly question whether we should revert this feature ..."

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+                     Ancient Roman grave inscription +