On Wed, 2011-04-20 at 17:52 +0100, Greg Stark wrote: > I admit though this whole concept of "finished patches" seems foreign > to me. I always have additional stuff I want to do and if the patch > sits on the shelf I'm essentially stuck unable to work on the next > great thing that that patch enables. Developers either have the option > to go off on their own with no feedback and risk having initial > assumptions questioned later and all their work invalidated or go and > work on something unrelated leaving this direction stunted with only > one round of features implemented. I think this is how we ended up > with partitioning that's only halfway useful and selinux that had tons > of code written that needed to be reworked.
Yeah, there appear to be occasional assumptions that one ought to work on one major feature per release, and ideally you'd have the plan ready for the first commit fest and the code mostly ready for the third commit fest. Whereas I agree with you that it's often rather the case that you want to work on say three incremental features, and order for that to work out under this process, you really have to get the first increment perfect for the first commit fest already. Which is difficult if no one pays attention until the commit fest starts. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
