On Fri, Jan 25, 2013 at 02:40:03AM +0100, Andres Freund wrote: > > > 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.
I have found that if I push out improvements right after they are requested, I can sometimes get momentum for people to get excited about the patch. That is very hard to do with any other time constraints. I am not saying you didn't push out stuff quickly, only that this is hard to do. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
