hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Todd Lipcon <t...@cloudera.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:29:54 GMT
On Wed, May 12, 2010 at 8:16 AM, Jonathan Gray <jgray@facebook.com> wrote:
> Thanks for digging more stack.
>
> I agree that after going over the diffs between branch and trunk, the better choice is
to switch to trunk and merge in the stuff that went into branch that didn't make it into trunk.
 I went through the list of what's in trunk and not branch twice last night and there's really
nothing significant outside of replication, test refactoring, shell stuff, and some HLog fixes/refactors.
 Lots of stability/testing work still needs to be done around HLog and recovery but we should
do it against trunk where some good stuff has already gone in.
>
> However, I'm only for doing this if we can get it done very soon.  It's going to be
disruptive to those of us working against branch right now and so the sooner the better.  It
doesn't make sense to start developing on trunk before we merge stuff from branch in, especially
HBASE-2248.  Of the list you made Stack, it seems like this is the only critical piece that
also significantly changes large portions of the code.
>
> Some of the other smaller jiras that were done against branch only could trickle in after
the move, if necessary, but 2248 at least appears to be a blocker to doing this transition.

+1, if Ryan thinks that 2248 is doable this week, it seems like the
best of our options.

>
> Ryan, are you comfortable with this?
>
> 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.

> 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.

>
> Anyone with major objections to any of this?  We should move to a vote soon.
>
> Also, I think we should adopt the practice of having a Release Manager for when we cut
the branch off trunk.

+1, I like the idea of RM.

-Todd

-- 
Todd Lipcon
Software Engineer, Cloudera

Mime
View raw message