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.