Re: logical changeset generation v4 - Heikki's thoughts about the patch state - Mailing list pgsql-hackers

From Andres Freund
Subject Re: logical changeset generation v4 - Heikki's thoughts about the patch state
Date
Msg-id 20130125014003.GC15706@awork2.anarazel.de
Whole thread Raw
In response to Re: logical changeset generation v4 - Heikki's thoughts about the patch state  (Bruce Momjian <bruce@momjian.us>)
Responses Re: logical changeset generation v4 - Heikki's thoughts about the patch state
List pgsql-hackers
On 2013-01-24 20:28:41 -0500, Bruce Momjian wrote:
> On Fri, Jan 25, 2013 at 02:16:09AM +0100, Andres Freund wrote:
> > What I am afraid though is that it basically goes on like this in the
> > next commitfests:
> > * 9.4-CF1: no "serious" reviewer comments because they are busy doing release work
> > * 9.4-CF2: all are relieved that the release is over and a bit tired
> > * 9.4-CF3: first deeper review, some more complex restructuring required
> > * 9.4-CF4: too many changes to commit.
> >
> > If you look at the development of the feature, after the first prototype
> > and the resulting design changes nobody with decision power had a more
> > than cursory look at the proposed interfaces. Thats very, very, very
> > understandable, you all are busy people and the patch & the interfaces
> > are complex so it takes noticeable amounts of time, but it unfortunately
> > doesn't help in getting an acceptable interface nailed down.
> >
> > The problem with that is not only that it sucks huge amounts of energy
> > out of me and others but also that its very hard to really build the
> > layers/users above changeset extraction without being able to rely on
> > the interface and semantics. So we never get to the actually benefits
> > :(, and we don't get the users people require for the feature to be
> > committed.
> >
> > So far, the only really effective way of getting people to comment on
> > patches in this state & complexity is the threat of an upcoming commit
> > because of the last commitfest :(
> >
> > I honestly don't know how to go on about this...
>
> This is very accurate and the big challenge of large, invasive patches.
> You almost need to hit it perfect the first time to get it committed in
> less than a year.

My primary concern really isn't to get it committed inside a year, but
to be sure to get input in-time to be able to actually continue to
work. And to commit it then. And I am absolutely, absolutely not sure
thats going to work.

Greetings,

Andres Freund

--Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap [Review]
Next
From: Craig Ringer
Date:
Subject: Re: Strange Windows problem, lock_timeout test request