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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
