On Wed, May 12, 2010 at 11:57 AM, Jonathan Gray <jg...@facebook.com> wrote:

> The idea would be to do this once new features will no longer be allowed and 
> anything but bug/stability fixes would not be allowed.  Either we branch off 
> trunk once we're ready to make that call, or we hold off on commits to trunk. 
>  I just recommend branching so new stuff can still be developed against 
> trunk.  In the past we've not been very strict about keeping trunk stable and 
> I think this has been to our advantage.  Obviously as we get bigger we need 
> to stabilize more but I'm not in the camp of wanting an always releasable 
> trunk.  An always working trunk is good.
>
> Do you think we should move to a feature branch model if we keep trunk 
> releasable?

I like feature branch models in general for any large
features/rewrites/etc, especially when not all of the community might
be sold on a particular feature (eg a contrib project just getting
started)

>
> We should definitely try to prevent split work between branches/trunk, but 
> this is really the first time it's happened in HBase land.  I think chasing 
> Hadoop appends and the lack of Hadoop releases has a lot to do with how we 
> got here.

Yep, true enough.

-Todd

-- 
Todd Lipcon
Software Engineer, Cloudera

Reply via email to