Public GitHub tree for HBASE-10191 work

[Andrew Purtell <ap...@apache.org>]

I generally prefer to do development in trunk instead of feature branches
but the changes for HBASE-10191 will be a series of tasks executed over a
longish period of time and will probably involve some backtracking.
Therefore, like what we did with snapshots, I'd like to do development in a
GitHub hosted branch to allow collaboration and experimentation with the
added bonus of code review by pull request, although any committer who
requests I'll gladly add as a collaborator to grant push access.

The tree is here: https://github.com/apurtell/hbase/tree/HBASE-10191

Any concerns?

-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: Public GitHub tree for HBASE-10191 work

[Jonathan Hsieh <jo...@cloudera.com>]

After a few painful rebases we switched to doing snapshots from a known
good point and focused our efforts on that branch for a while until we got
the snapshots part stable.  Only after we had online snapshots at a known
good point we started remerging with trunk.  It took a bit of of time
reconciling and hardening against the periodic merges before the merge into
the the trunk branch.  We had reviews on the merges too if I recall -- this
way all the changes could be taken into account, all patches got reviewed,
and each commits was compilable and testable.

Snapshots however was a fairly isolated feature.

Jon.





On Wed, Feb 19, 2014 at 6:26 PM, Enis Söztutar <en...@apache.org> wrote:

> Sounds good.
>
> We had a working branch for HBASE-10070 in github (that is also publicized
> this way), and now we moved to an svn branch so that commits are going to
> that branch after reviews in jira. We also have hbase-10070 release tag in
> jira for assigning fix versions to issues while resolving them. This has
> worked so far.
>
> The most painful thing is to rebase the patches, because the base patches
> change because of review comments, but it is not unmanageable.
>
> Enis
>
>
> On Wed, Feb 19, 2014 at 6:17 PM, Andrew Purtell <ap...@apache.org>
> wrote:
>
> > On Wed, Feb 19, 2014 at 5:35 PM, Nick Dimiduk <nd...@gmail.com>
> wrote:
> >
> > > I would also recommend you take an aggressive stance on rebasing this
> > > branch onto trunk to keep things fresh. You'll need to work out the
> > details
> > > with your collaborators though.
> > >
> >
> > Agreed. I'd like to ultimately keep the work apart as a stack of patches
> > floating atop HBase trunk, rather than have a bunch of small commits with
> > poorly descriptive commit messages threaded throughout branch history.
> > Maybe a weekly Sunday rebase (perhaps with squashing) and force push
> would
> > not be too onerous.
> >
> > --
> > Best regards,
> >
> >    - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
>



-- 
// Jonathan Hsieh (shay)
// HBase Tech Lead, Software Engineer, Cloudera
// jon@cloudera.com // @jmhsieh

Re: Public GitHub tree for HBASE-10191 work

[Enis Söztutar <en...@apache.org>]

Sounds good.

We had a working branch for HBASE-10070 in github (that is also publicized
this way), and now we moved to an svn branch so that commits are going to
that branch after reviews in jira. We also have hbase-10070 release tag in
jira for assigning fix versions to issues while resolving them. This has
worked so far.

The most painful thing is to rebase the patches, because the base patches
change because of review comments, but it is not unmanageable.

Enis


On Wed, Feb 19, 2014 at 6:17 PM, Andrew Purtell <ap...@apache.org> wrote:

> On Wed, Feb 19, 2014 at 5:35 PM, Nick Dimiduk <nd...@gmail.com> wrote:
>
> > I would also recommend you take an aggressive stance on rebasing this
> > branch onto trunk to keep things fresh. You'll need to work out the
> details
> > with your collaborators though.
> >
>
> Agreed. I'd like to ultimately keep the work apart as a stack of patches
> floating atop HBase trunk, rather than have a bunch of small commits with
> poorly descriptive commit messages threaded throughout branch history.
> Maybe a weekly Sunday rebase (perhaps with squashing) and force push would
> not be too onerous.
>
> --
> Best regards,
>
>    - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>

Re: Public GitHub tree for HBASE-10191 work

[Andrew Purtell <ap...@apache.org>]

On Wed, Feb 19, 2014 at 5:35 PM, Nick Dimiduk <nd...@gmail.com> wrote:

> I would also recommend you take an aggressive stance on rebasing this
> branch onto trunk to keep things fresh. You'll need to work out the details
> with your collaborators though.
>

Agreed. I'd like to ultimately keep the work apart as a stack of patches
floating atop HBase trunk, rather than have a bunch of small commits with
poorly descriptive commit messages threaded throughout branch history.
Maybe a weekly Sunday rebase (perhaps with squashing) and force push would
not be too onerous.

-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: Public GitHub tree for HBASE-10191 work

[Nick Dimiduk <nd...@gmail.com>]

Sounds good to me.

I would also recommend you take an aggressive stance on rebasing this
branch onto trunk to keep things fresh. You'll need to work out the details
with your collaborators though. It would also be interesting to wire this
up to Travis CI [0].

[0]: http://docs.travis-ci.com/user/languages/java/


On Wed, Feb 19, 2014 at 5:23 PM, Andrew Purtell <ap...@apache.org> wrote:

> I generally prefer to do development in trunk instead of feature branches
> but the changes for HBASE-10191 will be a series of tasks executed over a
> longish period of time and will probably involve some backtracking.
> Therefore, like what we did with snapshots, I'd like to do development in a
> GitHub hosted branch to allow collaboration and experimentation with the
> added bonus of code review by pull request, although any committer who
> requests I'll gladly add as a collaborator to grant push access.
>
> The tree is here: https://github.com/apurtell/hbase/tree/HBASE-10191
>
> Any concerns?
>
> --
> Best regards,
>
>    - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>