Re: Future In-Core Replication

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Future In-Core Replication
Дата
Msg-id CA+TgmoZBJHC+5k+qqkNzzBk3eGASmuWv6aWHAv4RhLE8UgE=Pg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Future In-Core Replication  (Greg Smith <greg@2ndQuadrant.com>)
Ответы Re: Future In-Core Replication  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
On Fri, May 4, 2012 at 11:06 AM, Greg Smith <greg@2ndquadrant.com> wrote:
> The straw man argument here would require 100% transparency on everything
> you do in regards to PostgreSQL and related software.  Before doing any
> development on any code, first post here to ask for design review.  And if
> someone asks you to work on a program that isn't open source from day one,
> refuse unless you can operate that transparently.

Well, look.  At the end of the day, I don't really care whether you
post your designs before writing code or not - unless it turns out
that we get to the end of the development cycle, a gigantic patch
shows up at the last minute, it gets rejected because people aren't
satisfied with the design, and then massive bitching ensues because
the author(s) put a lot of work into that patch.  Then I care, because
now the fact that no design consensus was sought at the outset has
been transformed into a defect in the community process, which does in
fact have defects, but that isn't one of them.  We all know that
design review is going to have to happen at some point, and if there's
not an adequate opportunity to do that before the code is written then
it will happen after the code is written.  If that means the code has
to be thrown out, then that's the risk you take by writing the code
first.  As long as everybody understands that, do it in whatever order
you like.

I think the real straw man here is the idea that it will somehow save
time to skip the design phase and start writing code.  I have never
worked on a project, open source or otherwise, where that was true,
and I believe that any textbook on software engineering you pick up is
likely to tell you that in fact exactly the opposite is the case.

Obviously, there are times when you need to write some throw-away code
just to see how things shake out, and I do that all the time, and it
makes complete sense, and I'm not knocking it.  But if any of that
code makes it into the committed patch, I count that as unusually
lucky.

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


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

Предыдущее
От: Greg Smith
Дата:
Сообщение: Re: Future In-Core Replication
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: JSON in 9.2 - Could we have just one to_json() function instead of two separate versions ?