Open Stack

On 04/29/2013 06:48 PM, Russell Bryant wrote:
> On 04/29/2013 06:39 PM, Sullivan, Jon Paul wrote:
>>
>> I think this article gives a good argument for "disabled-by-default".  It is a valid way to retain small commits to the code base which are easily reviewable whilst enabling developers to continue development on the feature in a safe way.  Without this you may lose the ability to keep commits small enough to be digestible to reviewers.
>>
>> http://rc3.org/2013/03/03/dont-get-stuck/
>
> I think you can develop a feature in its entirety with a series of
> reasonably sized changes with a well designed patch set.
>
> Once code gets in to the tree, it becomes a burden on the project to
> maintain that code, even if disabled by default.  If your feature isn't
> done, I don't want it in the tree.

+1.

The etsy example breaks down in the community in that there is no reason 
someone's half baked code is actually going to get completed later. 
Until it's working, it's technical debt, and, honestly is probably going 
to be deleted by one of the many janitors that run through purging 
unused / unusable code.

Make a clean patch series, a high priority blueprint, and let folks know 
review time is needed. I've seen new blueprints land in only a couple of 
days when structured and flagged as such, and the community knows it's 
coming.

Also, there is no reason to loose small commits as the feature grows. 
git rebase -i is your friend, and it's easy enough to keep things as a 
sane patch series.

	-Sean

-- 
Sean Dague
http://dague.net