Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE - Mailing list pgsql-hackers

From Michael Meskes
Subject Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE
Date
Msg-id 182716b58372bc91ff951daa3e8e4e9a61bc279d.camel@postgresql.org
Whole thread Raw
In response to Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE
List pgsql-hackers
> My email of July 30 was itself pretty strongly worded, but went
> unanswered for a full week. Not even a token response. If that
> doesn't
> count as "ignoring the RMT", then what does? How much time has to
> pass
> before radio silence begins to count as "ignoring the RMT", in your
> view of things? A month? More?

If you want me to answer, how about asking a question? Or telling me
that you'd like some feedback? I don't see how I should know that you
expect a reply to a simple statement of facts.

> Okay, I understand that now.

And? Do you care at all?

> As Andrew pointed out, there is a general expectation that committers
> take care of their own open items. That doesn't mean that they are
> obligated to personally fix bugs. Just that the final responsibility
> to make sure that the issue is resolved rests with the committer.
> This
> is one of the few hard rules that we have.

Sure, I don't question that. Again, I knew about the issue, only
misjudged it in the beginning. Your email from July 30 did show me that
it was more urgent but still didn't create the impression that there
was such a short deadline. In my opinion my prior email already
explained that I was on it, but couldn't give an estimate.

> As I've said before, RMT-driven revert is something that I see as an
> option of last resort. The RMT charter doesn't go quite that far, but
> I'd argue that my interpretation is quite natural given how committer
> responsibility works in general. In other words, I personally believe
> that our bottom-up approach is on balance a good one, and should be
> preserved.

Fair enough, to me a revert is a revert, no matter who issues it.

> Maybe the issue is muddied by the fact that we each have different
> views of the community process, at a high level (I'm unsure). Unlike
> you, I don't believe that RMT-driven revert is "a reasonable
> procedure". I myself see the RMT's power to resolve open items in
> this
> way as a necessary evil. Something to be avoided at all costs. Why
> should people that don't know anything about ecpg make decisions
> about
> ecpg? In general they should not.

Well, you did lay out what the decision would be and I fully agreed
with it. So again, what was there to do? Had you asked me if I agreed,
I would told you. 

Michael

-- 
Michael Meskes
Michael at Fam-Meskes dot De
Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org




pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE
Next
From: Robert Haas
Date:
Subject: using an end-of-recovery record in all cases