Re: logical changeset generation v4 - Heikki's thoughts about the patch state
| От | Bruce Momjian |
|---|---|
| Тема | Re: logical changeset generation v4 - Heikki's thoughts about the patch state |
| Дата | |
| Msg-id | 20130125015515.GP21914@momjian.us обсуждение исходный текст |
| Ответ на | Re: logical changeset generation v4 - Heikki's thoughts about the patch state (Andres Freund <andres@2ndquadrant.com>) |
| Список | pgsql-hackers |
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. +
В списке pgsql-hackers по дате отправления: