Re: Key management with tests

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Key management with tests
Дата
Msg-id 20210116042036.cpuadvs2bdbsblia@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Key management with tests  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: Key management with tests  (Michael Paquier <michael@paquier.xyz>)
Re: Key management with tests  (Tom Kincaid <tomjohnkincaid@gmail.com>)
Список pgsql-hackers
Hi,

On 2021-01-15 20:49:10 -0500, Bruce Momjian wrote:
> On Fri, Jan 15, 2021 at 04:56:24PM -0800, Andres Freund wrote:
> > On 2021-01-15 19:21:32 -0500, Bruce Momjian wrote:
> > > You have to understand cryptography and Postgres internals to understand
> > > the design, and I don't think it is realistic to explain that all to the
> > > community.  We did much of this in voice calls over months because it
> > > was too much of a burden to explain all the cryptographic details so
> > > everyone could follow along.
> > 
> > I think that's not at all acceptable. I don't mind hashing out details
> > on calls / off-list, but the design needs to be public, documented, and
> > reviewable.  And if it's something the community can't understand, then
> > it can't get in. We're going to have to maintain this going forward.
> 
> OK, so we don't want it.  That's fine with me.

That's not what I said...


> > This isn't specific to this topic? I don't really understand why this
> > specific feature gets to avoid normal community development processes?
> 
> What is being avoided?

You previously pushed a patch without tests, now you want to push a
patch that was barely reviewed and also doesn't contain an explanation
of the design. I mean:

> > > You have to understand cryptography and Postgres internals to understand
> > > the design, and I don't think it is realistic to explain that all to the
> > > community.  We did much of this in voice calls over months because it
> > > was too much of a burden to explain all the cryptographic details so
> > > everyone could follow along.

really is very far from the normal community process. Again, how is this
supposed to be maintained in the future, if it's based on a design
that's only understandable to the people on those phone calls?


> > We have had perl tap tests for quite a while now? And all new tests that
> > aren't regression / isolation tests are expected to be written in it.
> 
> What Perl tap tests run initdb and manage the cluster?  I didn't find
> any.

find . -name '*.pl'|xargs grep 'use PostgresNode;'

should give you a nearly complete list.

Greetings,

Andres Freund



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

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: Is Recovery actually paused?
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Add table access method as an option to pgbench