2248 is going in soon, I'm working on it now.
On Wed, May 12, 2010 at 11:57 AM, Jonathan Gray <jg...@facebook.com> wrote: >> > If Ryan can do the port of 2248 to trunk this week, then I'm +1 on >> > merging branch into trunk. I would then think that in a 2-3 week >> > timeframe we would cut a new branch off of trunk and stabilize it. >> > >> >> I am sort of +0 on cutting a new branch at that point. What I would >> prefer to see is moving towards an "always releasable trunk" model, in >> that stuff doesn't go into trunk unless it's reasonably usable. Large >> changes should be done in feature branches before getting committed. >> Otherwise, my fear is that we're just going to end up in this >> situation again in 6 months. > > 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? > > 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. > >> > I would vote for making that branch 0.90. I would also vote for >> doing anything else big/disruptive/compatibility breaking at the same >> time we all move onto trunk and kill the branch. For example, the >> switch to org.apache.hbase should happen now rather than later. Since >> trunk also includes some versioning stuff in the RPC, we'll be able to >> add stuff to the API moving forward without breaking client >> compatibility, so it seems like breaking it all now is a good idea. We >> may not need to break it again for whatever comes after 0.90. Also >> remember, the old APIs are already ripped out of trunk. >> >> The big changes that we do for this new branch should happen before >> the branch is cut, not after - otherwise we'll have the same problem >> where the two branches are so far apart that merges are impossible. > > Maybe I wasn't clear. My vote is to do the disruptive stuff immediately with > the move to trunk, well before we would cut a branch off trunk for release. > Branching would happen once the release manager decides it's time to cut the > branch. For anything besides bug fixes, it would be up to the RM to cherry > pick anything from trunk for the branch. It's also not such a big deal to > apply to branch+trunk once they are close together... right now some > logistical stuff like directory structures and some refactoring makes it more > of a pain than normal. > > JG >
