Re: Future In-Core Replication - Mailing list pgsql-hackers
From | Andres Freund |
---|---|
Subject | Re: Future In-Core Replication |
Date | |
Msg-id | 201205041859.41675.andres@2ndquadrant.com Whole thread Raw |
In response to | Re: Future In-Core Replication (Robert Haas <robertmhaas@gmail.com>) |
Responses |
Re: Future In-Core Replication
|
List | pgsql-hackers |
Hi Robert, Hi all, On Friday, May 04, 2012 06:29:33 PM Robert Haas wrote: > 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. In my understanding - as the person doing quite a bit of the coding atm - the point is to provide a very minimal *early* prototype to have a sensible basis for design decisions/discussions. On one side thats useful to get a feeling for the problems involved. On the other side doing design discussions without an underlaying basic patch & design on -hackers tends to often go into directions of feature creep and bikeshedding. It also helps against "this is impossible" claims. Parts of this thread and related ones are a somewhat good example of this. The plan is to show the early prototype around pgcon and send design documents and split-up patches (of that prototype) a holiday and some cleanup later to - hackers. I/We aim to have individual, independently usable, parts of the patch submitted to the first 9.3 commitfest. I definitely do not wish to screw anyone over doing this or such. And I am sure thats the same with others working on this. Even if sometimes emotions get in the way/into play. Greetings, Andres -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
pgsql-hackers by date: