Feature branch for master rewrite

[Jonathan Gray <jg...@facebook.com>]

Hey guys,

So it's been a clunky and slow-moving process with HBASE-2694 and related JIRAs.

The most recent HBASE-2697 patch is supposed to be non-controversial but is in fact controversial because there's really not much context to the changes.

Instead of trying to make smallish patches that are each individually reviewable, the consensus is that we should make a feature branch so that our ideas can be seen through but still in a public forum.  In the end we'll end up with a branch which can be independently tested, a series of patches that got us here, and incremental (but non-blocking) reviews along the way.

Unless there is major opposition I'm going to cut the branch tonight.

JG

Re: Feature branch for master rewrite

[Ryan Rawson <ry...@gmail.com>]

+1 make it happen if it hasnt yet :-)

On Thu, Jun 24, 2010 at 8:15 PM, Jonathan Gray <jg...@facebook.com> wrote:
> That's the plan.  Thanks guys.
>
>> -----Original Message-----
>> From: Todd Lipcon [mailto:todd@cloudera.com]
>> Sent: Thursday, June 24, 2010 5:30 PM
>> To: dev@hbase.apache.org
>> Subject: Re: Feature branch for master rewrite
>>
>> +1, sounds good to me, too.
>>
>> But let's please make sure there are periodic merges from trunk into
>> the
>> feature branch, so that we don't have merge hell in a month when we
>> want to
>> merge back!
>>
>> -Todd
>>
>> On Thu, Jun 24, 2010 at 5:23 PM, Jean-Daniel Cryans
>> <jd...@apache.org>wrote:
>>
>> > Supportive +1, it's hard for us to see the big picture through the
>> > stream of patches and I think creating that branch goes hand in hand
>> > with what was said at the Hadoop Contributors meetup (not that we are
>> > tied to what was said there, but I remember that we all agreed that
>> it
>> > was a good model for HBase too).
>> >
>> > J-D
>> >
>> > On Thu, Jun 24, 2010 at 5:17 PM, Jonathan Gray <jg...@facebook.com>
>> wrote:
>> > > Hey guys,
>> > >
>> > > So it's been a clunky and slow-moving process with HBASE-2694 and
>> related
>> > JIRAs.
>> > >
>> > > The most recent HBASE-2697 patch is supposed to be non-
>> controversial but
>> > is in fact controversial because there's really not much context to
>> the
>> > changes.
>> > >
>> > > Instead of trying to make smallish patches that are each
>> individually
>> > reviewable, the consensus is that we should make a feature branch so
>> that
>> > our ideas can be seen through but still in a public forum.  In the
>> end we'll
>> > end up with a branch which can be independently tested, a series of
>> patches
>> > that got us here, and incremental (but non-blocking) reviews along
>> the way.
>> > >
>> > > Unless there is major opposition I'm going to cut the branch
>> tonight.
>> > >
>> > > JG
>> > >
>> >
>>
>>
>>
>> --
>> Todd Lipcon
>> Software Engineer, Cloudera
>

RE: Feature branch for master rewrite

[Jonathan Gray <jg...@facebook.com>]

That's the plan.  Thanks guys.

> -----Original Message-----
> From: Todd Lipcon [mailto:todd@cloudera.com]
> Sent: Thursday, June 24, 2010 5:30 PM
> To: dev@hbase.apache.org
> Subject: Re: Feature branch for master rewrite
> 
> +1, sounds good to me, too.
> 
> But let's please make sure there are periodic merges from trunk into
> the
> feature branch, so that we don't have merge hell in a month when we
> want to
> merge back!
> 
> -Todd
> 
> On Thu, Jun 24, 2010 at 5:23 PM, Jean-Daniel Cryans
> <jd...@apache.org>wrote:
> 
> > Supportive +1, it's hard for us to see the big picture through the
> > stream of patches and I think creating that branch goes hand in hand
> > with what was said at the Hadoop Contributors meetup (not that we are
> > tied to what was said there, but I remember that we all agreed that
> it
> > was a good model for HBase too).
> >
> > J-D
> >
> > On Thu, Jun 24, 2010 at 5:17 PM, Jonathan Gray <jg...@facebook.com>
> wrote:
> > > Hey guys,
> > >
> > > So it's been a clunky and slow-moving process with HBASE-2694 and
> related
> > JIRAs.
> > >
> > > The most recent HBASE-2697 patch is supposed to be non-
> controversial but
> > is in fact controversial because there's really not much context to
> the
> > changes.
> > >
> > > Instead of trying to make smallish patches that are each
> individually
> > reviewable, the consensus is that we should make a feature branch so
> that
> > our ideas can be seen through but still in a public forum.  In the
> end we'll
> > end up with a branch which can be independently tested, a series of
> patches
> > that got us here, and incremental (but non-blocking) reviews along
> the way.
> > >
> > > Unless there is major opposition I'm going to cut the branch
> tonight.
> > >
> > > JG
> > >
> >
> 
> 
> 
> --
> Todd Lipcon
> Software Engineer, Cloudera

Re: Feature branch for master rewrite

[Todd Lipcon <to...@cloudera.com>]

+1, sounds good to me, too.

But let's please make sure there are periodic merges from trunk into the
feature branch, so that we don't have merge hell in a month when we want to
merge back!

-Todd

On Thu, Jun 24, 2010 at 5:23 PM, Jean-Daniel Cryans <jd...@apache.org>wrote:

> Supportive +1, it's hard for us to see the big picture through the
> stream of patches and I think creating that branch goes hand in hand
> with what was said at the Hadoop Contributors meetup (not that we are
> tied to what was said there, but I remember that we all agreed that it
> was a good model for HBase too).
>
> J-D
>
> On Thu, Jun 24, 2010 at 5:17 PM, Jonathan Gray <jg...@facebook.com> wrote:
> > Hey guys,
> >
> > So it's been a clunky and slow-moving process with HBASE-2694 and related
> JIRAs.
> >
> > The most recent HBASE-2697 patch is supposed to be non-controversial but
> is in fact controversial because there's really not much context to the
> changes.
> >
> > Instead of trying to make smallish patches that are each individually
> reviewable, the consensus is that we should make a feature branch so that
> our ideas can be seen through but still in a public forum.  In the end we'll
> end up with a branch which can be independently tested, a series of patches
> that got us here, and incremental (but non-blocking) reviews along the way.
> >
> > Unless there is major opposition I'm going to cut the branch tonight.
> >
> > JG
> >
>



-- 
Todd Lipcon
Software Engineer, Cloudera

Re: Feature branch for master rewrite

[Jean-Daniel Cryans <jd...@apache.org>]

Supportive +1, it's hard for us to see the big picture through the
stream of patches and I think creating that branch goes hand in hand
with what was said at the Hadoop Contributors meetup (not that we are
tied to what was said there, but I remember that we all agreed that it
was a good model for HBase too).

J-D

On Thu, Jun 24, 2010 at 5:17 PM, Jonathan Gray <jg...@facebook.com> wrote:
> Hey guys,
>
> So it's been a clunky and slow-moving process with HBASE-2694 and related JIRAs.
>
> The most recent HBASE-2697 patch is supposed to be non-controversial but is in fact controversial because there's really not much context to the changes.
>
> Instead of trying to make smallish patches that are each individually reviewable, the consensus is that we should make a feature branch so that our ideas can be seen through but still in a public forum.  In the end we'll end up with a branch which can be independently tested, a series of patches that got us here, and incremental (but non-blocking) reviews along the way.
>
> Unless there is major opposition I'm going to cut the branch tonight.
>
> JG
>