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