hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Gray <jg...@facebook.com>
Subject RE: Merging 0.20 BRANCH and TRUNK WAS -> Re: JIRAs committed on trunk but not branch (take 2)
Date Wed, 12 May 2010 18:57:07 GMT
> > 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.


View raw message