[DISCUSS] Migrate from svn to git for source control?

[Karthik Kambatla <ka...@cloudera.com>]

Hi folks,

>From what I hear, a lot of devs use the git mirror for development/reviews
and use subversion primarily for checking code in. I was wondering if it
would make more sense just to move to git. In addition to subjective liking
of git, I see the following advantages in our workflow:

   1. Feature branches - it becomes easier to work on them and keep
   rebasing against the latest trunk.
   2. Cherry-picks between branches automatically ensures the exact same
   commit message and tracks the lineage as well.
   3. When cutting new branches and/or updating maven versions etc., it
   allows doing all the work locally before pushing it to the main branch.
   4. Opens us up to potentially using other code-review tools. (Gerrit?)
   5. It is just more convenient.

I am sure this was brought up before in different capacities. I believe the
support for git in ASF is healthy now and several downstream projects have
moved. Again, from what I hear, ASF INFRA folks make the migration process
fairly easy.

What do you all think?

Thanks
Karthik

Re: [DISCUSS] Migrate from svn to git for source control?

[Andrew Wang <an...@cloudera.com>]

Thanks for starting this thread Karthik! Big +1 from me. I only use svn
when I have to commit things or work on the site, otherwise it's always the
git mirror or local git repos.

Considering that the git mirror works as well as it does, I'd expect this
to be a pretty smooth transition.

Best,
Andrew


On Fri, Aug 1, 2014 at 4:43 PM, Karthik Kambatla <ka...@cloudera.com> wrote:

> Hi folks,
>
> From what I hear, a lot of devs use the git mirror for development/reviews
> and use subversion primarily for checking code in. I was wondering if it
> would make more sense just to move to git. In addition to subjective liking
> of git, I see the following advantages in our workflow:
>
>    1. Feature branches - it becomes easier to work on them and keep
>    rebasing against the latest trunk.
>    2. Cherry-picks between branches automatically ensures the exact same
>    commit message and tracks the lineage as well.
>    3. When cutting new branches and/or updating maven versions etc., it
>    allows doing all the work locally before pushing it to the main branch.
>    4. Opens us up to potentially using other code-review tools. (Gerrit?)
>    5. It is just more convenient.
>
> I am sure this was brought up before in different capacities. I believe the
> support for git in ASF is healthy now and several downstream projects have
> moved. Again, from what I hear, ASF INFRA folks make the migration process
> fairly easy.
>
> What do you all think?
>
> Thanks
> Karthik
>

Re: [DISCUSS] Migrate from svn to git for source control?

[Alejandro Abdelnur <tu...@gmail.com>]

+1, we did it for Oozie a while back and was painless with minor issues in
Jenkins jobs

Rebasing feature branches on latest trunk may be tricky as that may require
a force push and if I'm not mistaken force pushes are disabled in Apache
GIT.

thx


On Fri, Aug 1, 2014 at 4:43 PM, Karthik Kambatla <ka...@cloudera.com> wrote:

> Hi folks,
>
> From what I hear, a lot of devs use the git mirror for development/reviews
> and use subversion primarily for checking code in. I was wondering if it
> would make more sense just to move to git. In addition to subjective liking
> of git, I see the following advantages in our workflow:
>
>    1. Feature branches - it becomes easier to work on them and keep
>    rebasing against the latest trunk.
>    2. Cherry-picks between branches automatically ensures the exact same
>    commit message and tracks the lineage as well.
>    3. When cutting new branches and/or updating maven versions etc., it
>    allows doing all the work locally before pushing it to the main branch.
>    4. Opens us up to potentially using other code-review tools. (Gerrit?)
>    5. It is just more convenient.
>
> I am sure this was brought up before in different capacities. I believe the
> support for git in ASF is healthy now and several downstream projects have
> moved. Again, from what I hear, ASF INFRA folks make the migration process
> fairly easy.
>
> What do you all think?
>
> Thanks
> Karthik
>

Re: [DISCUSS] Migrate from svn to git for source control?

[Andrew Wang <an...@cloudera.com>]

In the bylaws, I see this under PMC responsibilities:

* Maintaining the project's shared resources, including the codebase
repository, mailing lists, websites.

This seems to indicate that the repo (i.e. svn or git) is managed by the
PMC. Of the available PMC vote actions, the closest seems to be "Adoption
of New Codebase":

When the codebase for an existing, released product is to be replaced with
an alternative codebase. If such a vote fails to gain approval, the
existing code base will continue.
This also covers the creation of new sub-projects within the project
Lazy 2/3 majority of PMC members

This would be my recommendation for the vote, but I'll defer to more
experienced PMC members.

Thanks,
Andrew


On Fri, Aug 8, 2014 at 1:18 PM, Alejandro Abdelnur <tu...@cloudera.com>
wrote:

> funny, i'd treat it as a merge vote.
>
>
> On Fri, Aug 8, 2014 at 11:44 AM, Karthik Kambatla <ka...@cloudera.com>
> wrote:
>
> > Thanks Steve. Including that in the proposal.
> >
> > By the way, from our project bylaws (
> http://hadoop.apache.org/bylaws.html
> > ),
> > I can't tell what kind of a vote this would be.
> >
> >
> > On Thu, Aug 7, 2014 at 1:22 AM, Steve Loughran <st...@hortonworks.com>
> > wrote:
> >
> > > On 6 August 2014 22:16, Karthik Kambatla <ka...@cloudera.com> wrote:
> > >
> > > > 3. Force-push on feature-branches is allowed. Before pulling in a
> > > feature,
> > > > the feature-branch should be rebased on latest trunk and the changes
> > > > applied to trunk through "git rebase --onto" or "git cherry-pick
> > > > <commit-range>".
> > > >
> > >
> > > I'd add to this process the requirement to tag any feature branch
> before
> > a
> > > rebase, with some standard naming like
> > >
> > > tag_feature_JIRA-2454_2014-08-07_rebase
> > >
> > > Why? it keeps the state of the branch before the rebase in case you
> ever
> > > want it back again. Without the tag: lost data. Once the feature is
> > merged
> > > in you can rm the tags, but until then they give you a log of what
> > changes
> > > went on, and make it possible to switch back to the pre-rebase version.
> > >
> > > Without those tags you do lose history of the development.
> > >
> > > --
> > > CONFIDENTIALITY NOTICE
> > > NOTICE: This message is intended for the use of the individual or
> entity
> > to
> > > which it is addressed and may contain information that is confidential,
> > > privileged and exempt from disclosure under applicable law. If the
> reader
> > > of this message is not the intended recipient, you are hereby notified
> > that
> > > any printing, copying, dissemination, distribution, disclosure or
> > > forwarding of this communication is strictly prohibited. If you have
> > > received this communication in error, please contact the sender
> > immediately
> > > and delete it from your system. Thank You.
> > >
> >
>
>
>
> --
> Alejandro
>

Re: [DISCUSS] Migrate from svn to git for source control?

[Andrew Wang <an...@cloudera.com>]

In the bylaws, I see this under PMC responsibilities:

* Maintaining the project's shared resources, including the codebase
repository, mailing lists, websites.

This seems to indicate that the repo (i.e. svn or git) is managed by the
PMC. Of the available PMC vote actions, the closest seems to be "Adoption
of New Codebase":

When the codebase for an existing, released product is to be replaced with
an alternative codebase. If such a vote fails to gain approval, the
existing code base will continue.
This also covers the creation of new sub-projects within the project
Lazy 2/3 majority of PMC members

This would be my recommendation for the vote, but I'll defer to more
experienced PMC members.

Thanks,
Andrew


On Fri, Aug 8, 2014 at 1:18 PM, Alejandro Abdelnur <tu...@cloudera.com>
wrote:

> funny, i'd treat it as a merge vote.
>
>
> On Fri, Aug 8, 2014 at 11:44 AM, Karthik Kambatla <ka...@cloudera.com>
> wrote:
>
> > Thanks Steve. Including that in the proposal.
> >
> > By the way, from our project bylaws (
> http://hadoop.apache.org/bylaws.html
> > ),
> > I can't tell what kind of a vote this would be.
> >
> >
> > On Thu, Aug 7, 2014 at 1:22 AM, Steve Loughran <st...@hortonworks.com>
> > wrote:
> >
> > > On 6 August 2014 22:16, Karthik Kambatla <ka...@cloudera.com> wrote:
> > >
> > > > 3. Force-push on feature-branches is allowed. Before pulling in a
> > > feature,
> > > > the feature-branch should be rebased on latest trunk and the changes
> > > > applied to trunk through "git rebase --onto" or "git cherry-pick
> > > > <commit-range>".
> > > >
> > >
> > > I'd add to this process the requirement to tag any feature branch
> before
> > a
> > > rebase, with some standard naming like
> > >
> > > tag_feature_JIRA-2454_2014-08-07_rebase
> > >
> > > Why? it keeps the state of the branch before the rebase in case you
> ever
> > > want it back again. Without the tag: lost data. Once the feature is
> > merged
> > > in you can rm the tags, but until then they give you a log of what
> > changes
> > > went on, and make it possible to switch back to the pre-rebase version.
> > >
> > > Without those tags you do lose history of the development.
> > >
> > > --
> > > CONFIDENTIALITY NOTICE
> > > NOTICE: This message is intended for the use of the individual or
> entity
> > to
> > > which it is addressed and may contain information that is confidential,
> > > privileged and exempt from disclosure under applicable law. If the
> reader
> > > of this message is not the intended recipient, you are hereby notified
> > that
> > > any printing, copying, dissemination, distribution, disclosure or
> > > forwarding of this communication is strictly prohibited. If you have
> > > received this communication in error, please contact the sender
> > immediately
> > > and delete it from your system. Thank You.
> > >
> >
>
>
>
> --
> Alejandro
>

Re: [DISCUSS] Migrate from svn to git for source control?

[Andrew Wang <an...@cloudera.com>]

In the bylaws, I see this under PMC responsibilities:

* Maintaining the project's shared resources, including the codebase
repository, mailing lists, websites.

This seems to indicate that the repo (i.e. svn or git) is managed by the
PMC. Of the available PMC vote actions, the closest seems to be "Adoption
of New Codebase":

When the codebase for an existing, released product is to be replaced with
an alternative codebase. If such a vote fails to gain approval, the
existing code base will continue.
This also covers the creation of new sub-projects within the project
Lazy 2/3 majority of PMC members

This would be my recommendation for the vote, but I'll defer to more
experienced PMC members.

Thanks,
Andrew


On Fri, Aug 8, 2014 at 1:18 PM, Alejandro Abdelnur <tu...@cloudera.com>
wrote:

> funny, i'd treat it as a merge vote.
>
>
> On Fri, Aug 8, 2014 at 11:44 AM, Karthik Kambatla <ka...@cloudera.com>
> wrote:
>
> > Thanks Steve. Including that in the proposal.
> >
> > By the way, from our project bylaws (
> http://hadoop.apache.org/bylaws.html
> > ),
> > I can't tell what kind of a vote this would be.
> >
> >
> > On Thu, Aug 7, 2014 at 1:22 AM, Steve Loughran <st...@hortonworks.com>
> > wrote:
> >
> > > On 6 August 2014 22:16, Karthik Kambatla <ka...@cloudera.com> wrote:
> > >
> > > > 3. Force-push on feature-branches is allowed. Before pulling in a
> > > feature,
> > > > the feature-branch should be rebased on latest trunk and the changes
> > > > applied to trunk through "git rebase --onto" or "git cherry-pick
> > > > <commit-range>".
> > > >
> > >
> > > I'd add to this process the requirement to tag any feature branch
> before
> > a
> > > rebase, with some standard naming like
> > >
> > > tag_feature_JIRA-2454_2014-08-07_rebase
> > >
> > > Why? it keeps the state of the branch before the rebase in case you
> ever
> > > want it back again. Without the tag: lost data. Once the feature is
> > merged
> > > in you can rm the tags, but until then they give you a log of what
> > changes
> > > went on, and make it possible to switch back to the pre-rebase version.
> > >
> > > Without those tags you do lose history of the development.
> > >
> > > --
> > > CONFIDENTIALITY NOTICE
> > > NOTICE: This message is intended for the use of the individual or
> entity
> > to
> > > which it is addressed and may contain information that is confidential,
> > > privileged and exempt from disclosure under applicable law. If the
> reader
> > > of this message is not the intended recipient, you are hereby notified
> > that
> > > any printing, copying, dissemination, distribution, disclosure or
> > > forwarding of this communication is strictly prohibited. If you have
> > > received this communication in error, please contact the sender
> > immediately
> > > and delete it from your system. Thank You.
> > >
> >
>
>
>
> --
> Alejandro
>

Re: [DISCUSS] Migrate from svn to git for source control?

[Andrew Wang <an...@cloudera.com>]

In the bylaws, I see this under PMC responsibilities:

* Maintaining the project's shared resources, including the codebase
repository, mailing lists, websites.

This seems to indicate that the repo (i.e. svn or git) is managed by the
PMC. Of the available PMC vote actions, the closest seems to be "Adoption
of New Codebase":

When the codebase for an existing, released product is to be replaced with
an alternative codebase. If such a vote fails to gain approval, the
existing code base will continue.
This also covers the creation of new sub-projects within the project
Lazy 2/3 majority of PMC members

This would be my recommendation for the vote, but I'll defer to more
experienced PMC members.

Thanks,
Andrew


On Fri, Aug 8, 2014 at 1:18 PM, Alejandro Abdelnur <tu...@cloudera.com>
wrote:

> funny, i'd treat it as a merge vote.
>
>
> On Fri, Aug 8, 2014 at 11:44 AM, Karthik Kambatla <ka...@cloudera.com>
> wrote:
>
> > Thanks Steve. Including that in the proposal.
> >
> > By the way, from our project bylaws (
> http://hadoop.apache.org/bylaws.html
> > ),
> > I can't tell what kind of a vote this would be.
> >
> >
> > On Thu, Aug 7, 2014 at 1:22 AM, Steve Loughran <st...@hortonworks.com>
> > wrote:
> >
> > > On 6 August 2014 22:16, Karthik Kambatla <ka...@cloudera.com> wrote:
> > >
> > > > 3. Force-push on feature-branches is allowed. Before pulling in a
> > > feature,
> > > > the feature-branch should be rebased on latest trunk and the changes
> > > > applied to trunk through "git rebase --onto" or "git cherry-pick
> > > > <commit-range>".
> > > >
> > >
> > > I'd add to this process the requirement to tag any feature branch
> before
> > a
> > > rebase, with some standard naming like
> > >
> > > tag_feature_JIRA-2454_2014-08-07_rebase
> > >
> > > Why? it keeps the state of the branch before the rebase in case you
> ever
> > > want it back again. Without the tag: lost data. Once the feature is
> > merged
> > > in you can rm the tags, but until then they give you a log of what
> > changes
> > > went on, and make it possible to switch back to the pre-rebase version.
> > >
> > > Without those tags you do lose history of the development.
> > >
> > > --
> > > CONFIDENTIALITY NOTICE
> > > NOTICE: This message is intended for the use of the individual or
> entity
> > to
> > > which it is addressed and may contain information that is confidential,
> > > privileged and exempt from disclosure under applicable law. If the
> reader
> > > of this message is not the intended recipient, you are hereby notified
> > that
> > > any printing, copying, dissemination, distribution, disclosure or
> > > forwarding of this communication is strictly prohibited. If you have
> > > received this communication in error, please contact the sender
> > immediately
> > > and delete it from your system. Thank You.
> > >
> >
>
>
>
> --
> Alejandro
>

Re: [DISCUSS] Migrate from svn to git for source control?

[Alejandro Abdelnur <tu...@cloudera.com>]

funny, i'd treat it as a merge vote.


On Fri, Aug 8, 2014 at 11:44 AM, Karthik Kambatla <ka...@cloudera.com>
wrote:

> Thanks Steve. Including that in the proposal.
>
> By the way, from our project bylaws (http://hadoop.apache.org/bylaws.html
> ),
> I can't tell what kind of a vote this would be.
>
>
> On Thu, Aug 7, 2014 at 1:22 AM, Steve Loughran <st...@hortonworks.com>
> wrote:
>
> > On 6 August 2014 22:16, Karthik Kambatla <ka...@cloudera.com> wrote:
> >
> > > 3. Force-push on feature-branches is allowed. Before pulling in a
> > feature,
> > > the feature-branch should be rebased on latest trunk and the changes
> > > applied to trunk through "git rebase --onto" or "git cherry-pick
> > > <commit-range>".
> > >
> >
> > I'd add to this process the requirement to tag any feature branch before
> a
> > rebase, with some standard naming like
> >
> > tag_feature_JIRA-2454_2014-08-07_rebase
> >
> > Why? it keeps the state of the branch before the rebase in case you ever
> > want it back again. Without the tag: lost data. Once the feature is
> merged
> > in you can rm the tags, but until then they give you a log of what
> changes
> > went on, and make it possible to switch back to the pre-rebase version.
> >
> > Without those tags you do lose history of the development.
> >
> > --
> > CONFIDENTIALITY NOTICE
> > NOTICE: This message is intended for the use of the individual or entity
> to
> > which it is addressed and may contain information that is confidential,
> > privileged and exempt from disclosure under applicable law. If the reader
> > of this message is not the intended recipient, you are hereby notified
> that
> > any printing, copying, dissemination, distribution, disclosure or
> > forwarding of this communication is strictly prohibited. If you have
> > received this communication in error, please contact the sender
> immediately
> > and delete it from your system. Thank You.
> >
>



-- 
Alejandro

Re: [DISCUSS] Migrate from svn to git for source control?

[Alejandro Abdelnur <tu...@cloudera.com>]

funny, i'd treat it as a merge vote.


On Fri, Aug 8, 2014 at 11:44 AM, Karthik Kambatla <ka...@cloudera.com>
wrote:

> Thanks Steve. Including that in the proposal.
>
> By the way, from our project bylaws (http://hadoop.apache.org/bylaws.html
> ),
> I can't tell what kind of a vote this would be.
>
>
> On Thu, Aug 7, 2014 at 1:22 AM, Steve Loughran <st...@hortonworks.com>
> wrote:
>
> > On 6 August 2014 22:16, Karthik Kambatla <ka...@cloudera.com> wrote:
> >
> > > 3. Force-push on feature-branches is allowed. Before pulling in a
> > feature,
> > > the feature-branch should be rebased on latest trunk and the changes
> > > applied to trunk through "git rebase --onto" or "git cherry-pick
> > > <commit-range>".
> > >
> >
> > I'd add to this process the requirement to tag any feature branch before
> a
> > rebase, with some standard naming like
> >
> > tag_feature_JIRA-2454_2014-08-07_rebase
> >
> > Why? it keeps the state of the branch before the rebase in case you ever
> > want it back again. Without the tag: lost data. Once the feature is
> merged
> > in you can rm the tags, but until then they give you a log of what
> changes
> > went on, and make it possible to switch back to the pre-rebase version.
> >
> > Without those tags you do lose history of the development.
> >
> > --
> > CONFIDENTIALITY NOTICE
> > NOTICE: This message is intended for the use of the individual or entity
> to
> > which it is addressed and may contain information that is confidential,
> > privileged and exempt from disclosure under applicable law. If the reader
> > of this message is not the intended recipient, you are hereby notified
> that
> > any printing, copying, dissemination, distribution, disclosure or
> > forwarding of this communication is strictly prohibited. If you have
> > received this communication in error, please contact the sender
> immediately
> > and delete it from your system. Thank You.
> >
>



-- 
Alejandro

Re: [DISCUSS] Migrate from svn to git for source control?

[Alejandro Abdelnur <tu...@cloudera.com>]

funny, i'd treat it as a merge vote.


On Fri, Aug 8, 2014 at 11:44 AM, Karthik Kambatla <ka...@cloudera.com>
wrote:

> Thanks Steve. Including that in the proposal.
>
> By the way, from our project bylaws (http://hadoop.apache.org/bylaws.html
> ),
> I can't tell what kind of a vote this would be.
>
>
> On Thu, Aug 7, 2014 at 1:22 AM, Steve Loughran <st...@hortonworks.com>
> wrote:
>
> > On 6 August 2014 22:16, Karthik Kambatla <ka...@cloudera.com> wrote:
> >
> > > 3. Force-push on feature-branches is allowed. Before pulling in a
> > feature,
> > > the feature-branch should be rebased on latest trunk and the changes
> > > applied to trunk through "git rebase --onto" or "git cherry-pick
> > > <commit-range>".
> > >
> >
> > I'd add to this process the requirement to tag any feature branch before
> a
> > rebase, with some standard naming like
> >
> > tag_feature_JIRA-2454_2014-08-07_rebase
> >
> > Why? it keeps the state of the branch before the rebase in case you ever
> > want it back again. Without the tag: lost data. Once the feature is
> merged
> > in you can rm the tags, but until then they give you a log of what
> changes
> > went on, and make it possible to switch back to the pre-rebase version.
> >
> > Without those tags you do lose history of the development.
> >
> > --
> > CONFIDENTIALITY NOTICE
> > NOTICE: This message is intended for the use of the individual or entity
> to
> > which it is addressed and may contain information that is confidential,
> > privileged and exempt from disclosure under applicable law. If the reader
> > of this message is not the intended recipient, you are hereby notified
> that
> > any printing, copying, dissemination, distribution, disclosure or
> > forwarding of this communication is strictly prohibited. If you have
> > received this communication in error, please contact the sender
> immediately
> > and delete it from your system. Thank You.
> >
>



-- 
Alejandro

Re: [DISCUSS] Migrate from svn to git for source control?

[Alejandro Abdelnur <tu...@cloudera.com>]

funny, i'd treat it as a merge vote.


On Fri, Aug 8, 2014 at 11:44 AM, Karthik Kambatla <ka...@cloudera.com>
wrote:

> Thanks Steve. Including that in the proposal.
>
> By the way, from our project bylaws (http://hadoop.apache.org/bylaws.html
> ),
> I can't tell what kind of a vote this would be.
>
>
> On Thu, Aug 7, 2014 at 1:22 AM, Steve Loughran <st...@hortonworks.com>
> wrote:
>
> > On 6 August 2014 22:16, Karthik Kambatla <ka...@cloudera.com> wrote:
> >
> > > 3. Force-push on feature-branches is allowed. Before pulling in a
> > feature,
> > > the feature-branch should be rebased on latest trunk and the changes
> > > applied to trunk through "git rebase --onto" or "git cherry-pick
> > > <commit-range>".
> > >
> >
> > I'd add to this process the requirement to tag any feature branch before
> a
> > rebase, with some standard naming like
> >
> > tag_feature_JIRA-2454_2014-08-07_rebase
> >
> > Why? it keeps the state of the branch before the rebase in case you ever
> > want it back again. Without the tag: lost data. Once the feature is
> merged
> > in you can rm the tags, but until then they give you a log of what
> changes
> > went on, and make it possible to switch back to the pre-rebase version.
> >
> > Without those tags you do lose history of the development.
> >
> > --
> > CONFIDENTIALITY NOTICE
> > NOTICE: This message is intended for the use of the individual or entity
> to
> > which it is addressed and may contain information that is confidential,
> > privileged and exempt from disclosure under applicable law. If the reader
> > of this message is not the intended recipient, you are hereby notified
> that
> > any printing, copying, dissemination, distribution, disclosure or
> > forwarding of this communication is strictly prohibited. If you have
> > received this communication in error, please contact the sender
> immediately
> > and delete it from your system. Thank You.
> >
>



-- 
Alejandro

Re: [DISCUSS] Migrate from svn to git for source control?

[Karthik Kambatla <ka...@cloudera.com>]

Thanks Steve. Including that in the proposal.

By the way, from our project bylaws (http://hadoop.apache.org/bylaws.html),
I can't tell what kind of a vote this would be.


On Thu, Aug 7, 2014 at 1:22 AM, Steve Loughran <st...@hortonworks.com>
wrote:

> On 6 August 2014 22:16, Karthik Kambatla <ka...@cloudera.com> wrote:
>
> > 3. Force-push on feature-branches is allowed. Before pulling in a
> feature,
> > the feature-branch should be rebased on latest trunk and the changes
> > applied to trunk through "git rebase --onto" or "git cherry-pick
> > <commit-range>".
> >
>
> I'd add to this process the requirement to tag any feature branch before a
> rebase, with some standard naming like
>
> tag_feature_JIRA-2454_2014-08-07_rebase
>
> Why? it keeps the state of the branch before the rebase in case you ever
> want it back again. Without the tag: lost data. Once the feature is merged
> in you can rm the tags, but until then they give you a log of what changes
> went on, and make it possible to switch back to the pre-rebase version.
>
> Without those tags you do lose history of the development.
>
> --
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
>

Re: [DISCUSS] Migrate from svn to git for source control?

[Karthik Kambatla <ka...@cloudera.com>]

Thanks Steve. Including that in the proposal.

By the way, from our project bylaws (http://hadoop.apache.org/bylaws.html),
I can't tell what kind of a vote this would be.


On Thu, Aug 7, 2014 at 1:22 AM, Steve Loughran <st...@hortonworks.com>
wrote:

> On 6 August 2014 22:16, Karthik Kambatla <ka...@cloudera.com> wrote:
>
> > 3. Force-push on feature-branches is allowed. Before pulling in a
> feature,
> > the feature-branch should be rebased on latest trunk and the changes
> > applied to trunk through "git rebase --onto" or "git cherry-pick
> > <commit-range>".
> >
>
> I'd add to this process the requirement to tag any feature branch before a
> rebase, with some standard naming like
>
> tag_feature_JIRA-2454_2014-08-07_rebase
>
> Why? it keeps the state of the branch before the rebase in case you ever
> want it back again. Without the tag: lost data. Once the feature is merged
> in you can rm the tags, but until then they give you a log of what changes
> went on, and make it possible to switch back to the pre-rebase version.
>
> Without those tags you do lose history of the development.
>
> --
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
>

Re: [DISCUSS] Migrate from svn to git for source control?

[Karthik Kambatla <ka...@cloudera.com>]

Thanks Steve. Including that in the proposal.

By the way, from our project bylaws (http://hadoop.apache.org/bylaws.html),
I can't tell what kind of a vote this would be.


On Thu, Aug 7, 2014 at 1:22 AM, Steve Loughran <st...@hortonworks.com>
wrote:

> On 6 August 2014 22:16, Karthik Kambatla <ka...@cloudera.com> wrote:
>
> > 3. Force-push on feature-branches is allowed. Before pulling in a
> feature,
> > the feature-branch should be rebased on latest trunk and the changes
> > applied to trunk through "git rebase --onto" or "git cherry-pick
> > <commit-range>".
> >
>
> I'd add to this process the requirement to tag any feature branch before a
> rebase, with some standard naming like
>
> tag_feature_JIRA-2454_2014-08-07_rebase
>
> Why? it keeps the state of the branch before the rebase in case you ever
> want it back again. Without the tag: lost data. Once the feature is merged
> in you can rm the tags, but until then they give you a log of what changes
> went on, and make it possible to switch back to the pre-rebase version.
>
> Without those tags you do lose history of the development.
>
> --
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
>

Re: [DISCUSS] Migrate from svn to git for source control?

[Karthik Kambatla <ka...@cloudera.com>]

Thanks Steve. Including that in the proposal.

By the way, from our project bylaws (http://hadoop.apache.org/bylaws.html),
I can't tell what kind of a vote this would be.


On Thu, Aug 7, 2014 at 1:22 AM, Steve Loughran <st...@hortonworks.com>
wrote:

> On 6 August 2014 22:16, Karthik Kambatla <ka...@cloudera.com> wrote:
>
> > 3. Force-push on feature-branches is allowed. Before pulling in a
> feature,
> > the feature-branch should be rebased on latest trunk and the changes
> > applied to trunk through "git rebase --onto" or "git cherry-pick
> > <commit-range>".
> >
>
> I'd add to this process the requirement to tag any feature branch before a
> rebase, with some standard naming like
>
> tag_feature_JIRA-2454_2014-08-07_rebase
>
> Why? it keeps the state of the branch before the rebase in case you ever
> want it back again. Without the tag: lost data. Once the feature is merged
> in you can rm the tags, but until then they give you a log of what changes
> went on, and make it possible to switch back to the pre-rebase version.
>
> Without those tags you do lose history of the development.
>
> --
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
>

Re: [DISCUSS] Migrate from svn to git for source control?

[Steve Loughran <st...@hortonworks.com>]

On 6 August 2014 22:16, Karthik Kambatla <ka...@cloudera.com> wrote:

> 3. Force-push on feature-branches is allowed. Before pulling in a feature,
> the feature-branch should be rebased on latest trunk and the changes
> applied to trunk through "git rebase --onto" or "git cherry-pick
> <commit-range>".
>

I'd add to this process the requirement to tag any feature branch before a
rebase, with some standard naming like

tag_feature_JIRA-2454_2014-08-07_rebase

Why? it keeps the state of the branch before the rebase in case you ever
want it back again. Without the tag: lost data. Once the feature is merged
in you can rm the tags, but until then they give you a log of what changes
went on, and make it possible to switch back to the pre-rebase version.

Without those tags you do lose history of the development.

-- 
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to 
which it is addressed and may contain information that is confidential, 
privileged and exempt from disclosure under applicable law. If the reader 
of this message is not the intended recipient, you are hereby notified that 
any printing, copying, dissemination, distribution, disclosure or 
forwarding of this communication is strictly prohibited. If you have 
received this communication in error, please contact the sender immediately 
and delete it from your system. Thank You.

Re: [DISCUSS] Migrate from svn to git for source control?

[Karthik Kambatla <ka...@cloudera.com>]

I plan to propose the following in the vote thread. Please advise on more
details to be added and/or concerns you have so we avoid the overhead of
doing this in the vote thread.

1. Migrate from subversion to git for version control
2. Force-push to be disabled on trunk and branch-* branches. Applying
changes from any of trunk/branch-* to any of branch-* should be through
"git cherry-pick -x".
3. Force-push on feature-branches is allowed. Before pulling in a feature,
the feature-branch should be rebased on latest trunk and the changes
applied to trunk through "git rebase --onto" or "git cherry-pick
<commit-range>".
4. The use of tags stay the same after the migration.

On Tue, Aug 5, 2014 at 11:41 PM, Andrew Wang <an...@cloudera.com>
wrote:

> By "merge-based workflow", this is referring to branch development and
> merging? I don't see much issue with allowing a rebase-based workflow if
> we're okay with allowing force-push on feature branches. If anything, the
> next step would be disallowing merge-based workflows and mandating rebases
> for a clean linear history, but it sounds like we'd rather not for now.
>
> Also, to state the obvious, for trunk->branch-2->etc backports, I'd expect
> us to be doing git cherry-picks.
>
> I think it'd be good to disable force-push for the main branches as Arpit
> recommends, we could include that in the VOTE as well.
>
> Thanks,
> Andrew
>
>
> On Tue, Aug 5, 2014 at 9:27 PM, Arpit Agarwal <aa...@hortonworks.com>
> wrote:
>
> > If by very same workflow you mean a merge-based workflow that would be
> fine
> > to call out in the vote proposal.
> >
> > Separately, do we want to disable force push for version branches
> > (branch-x) and point release branches (branch-x.y) in addition to trunk?
> >
> >
> > On Tue, Aug 5, 2014 at 8:18 PM, Alejandro Abdelnur <tu...@gmail.com>
> > wrote:
> >
> > > I would say we can first move to git and keep the very same workflow we
> > > have today, then we can evolve it.
> > >
> > >
> > > On Tue, Aug 5, 2014 at 6:46 PM, Arpit Agarwal <
> aagarwal@hortonworks.com>
> > > wrote:
> > >
> > > > +1 to voting on specific workflow(s).
> > > >
> > > >
> > > > On Tue, Aug 5, 2014 at 5:49 PM, Karthik Kambatla <kasha@cloudera.com
> >
> > > > wrote:
> > > >
> > > > > If we are to start a vote thread, will people prefer a vote thread
> > that
> > > > > includes potential workflows as well?
> > > > >
> > > > >
> > > > > On Tue, Aug 5, 2014 at 5:40 PM, Karthik Kambatla <
> kasha@cloudera.com
> > >
> > > > > wrote:
> > > > >
> > > > > > Thanks for your opinions, everyone. Looks like most people are
> for
> > > the
> > > > > > change and no one is against it. Let me start a vote for this.
> > > > > >
> > > > > >
> > > > > > On Mon, Aug 4, 2014 at 4:44 PM, Tsuyoshi OZAWA <
> > > > ozawa.tsuyoshi@gmail.com
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > >> Thank you for supplementation, Andrew. Yes, we should go step by
> > > step
> > > > > >> and let's discuss review workflows on a another thread.
> > > > > >>
> > > > > >> Thanks,
> > > > > >> - Tsuyoshi
> > > > > >>
> > > > > >> On Tue, Aug 5, 2014 at 8:23 AM, Andrew Wang <
> > > andrew.wang@cloudera.com
> > > > >
> > > > > >> wrote:
> > > > > >> > I think we should take things one step at a time. Switching to
> > git
> > > > > >> > definitely opens up the possibility for better review
> workflows,
> > > but
> > > > > we
> > > > > >> can
> > > > > >> > discuss that on a different thread.
> > > > > >> >
> > > > > >> > A few different people have also mentioned Gerrit, so that'd
> be
> > in
> > > > the
> > > > > >> > running along with Github (and I guess ReviewBoard).
> > > > > >> >
> > > > > >> > Thanks,
> > > > > >> > Andrew
> > > > > >> >
> > > > > >> >
> > > > > >> > On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA <
> > > > > >> ozawa.tsuyoshi@gmail.com>
> > > > > >> > wrote:
> > > > > >> >
> > > > > >> >> Thank you for great suggestion, Karthik. +1(non-binding) to
> use
> > > > git.
> > > > > >> >> I'm also using private git repository.
> > > > > >> >> Additionally, I have one question. Will we accept
> github-based
> > > > > >> >> development like Apache Spark? IHMO, it allow us to leverage
> > > Hadoop
> > > > > >> >> development, because the cost of sending pull request is very
> > low
> > > > and
> > > > > >> >> its review board is great. One concern is that the
> development
> > > > > >> >> workflow can change and it can confuse us. What do you think?
> > > > > >> >>
> > > > > >> >> Thanks,
> > > > > >> >> - Tsuyoshi
> > > > > >> >>
> > > > > >> >> On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla <
> > > > kasha@cloudera.com
> > > > > >
> > > > > >> >> wrote:
> > > > > >> >> > Hi folks,
> > > > > >> >> >
> > > > > >> >> > From what I hear, a lot of devs use the git mirror for
> > > > > >> >> development/reviews
> > > > > >> >> > and use subversion primarily for checking code in. I was
> > > > wondering
> > > > > >> if it
> > > > > >> >> > would make more sense just to move to git. In addition to
> > > > > subjective
> > > > > >> >> liking
> > > > > >> >> > of git, I see the following advantages in our workflow:
> > > > > >> >> >
> > > > > >> >> >    1. Feature branches - it becomes easier to work on them
> > and
> > > > keep
> > > > > >> >> >    rebasing against the latest trunk.
> > > > > >> >> >    2. Cherry-picks between branches automatically ensures
> the
> > > > exact
> > > > > >> same
> > > > > >> >> >    commit message and tracks the lineage as well.
> > > > > >> >> >    3. When cutting new branches and/or updating maven
> > versions
> > > > > etc.,
> > > > > >> it
> > > > > >> >> >    allows doing all the work locally before pushing it to
> the
> > > > main
> > > > > >> >> branch.
> > > > > >> >> >    4. Opens us up to potentially using other code-review
> > tools.
> > > > > >> (Gerrit?)
> > > > > >> >> >    5. It is just more convenient.
> > > > > >> >> >
> > > > > >> >> > I am sure this was brought up before in different
> > capacities. I
> > > > > >> believe
> > > > > >> >> the
> > > > > >> >> > support for git in ASF is healthy now and several
> downstream
> > > > > projects
> > > > > >> >> have
> > > > > >> >> > moved. Again, from what I hear, ASF INFRA folks make the
> > > > migration
> > > > > >> >> process
> > > > > >> >> > fairly easy.
> > > > > >> >> >
> > > > > >> >> > What do you all think?
> > > > > >> >> >
> > > > > >> >> > Thanks
> > > > > >> >> > Karthik
> > > > > >> >>
> > > > > >> >>
> > > > > >> >>
> > > > > >> >> --
> > > > > >> >> - Tsuyoshi
> > > > > >> >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> --
> > > > > >> - Tsuyoshi
> > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > > > --
> > > > CONFIDENTIALITY NOTICE
> > > > NOTICE: This message is intended for the use of the individual or
> > entity
> > > to
> > > > which it is addressed and may contain information that is
> confidential,
> > > > privileged and exempt from disclosure under applicable law. If the
> > reader
> > > > of this message is not the intended recipient, you are hereby
> notified
> > > that
> > > > any printing, copying, dissemination, distribution, disclosure or
> > > > forwarding of this communication is strictly prohibited. If you have
> > > > received this communication in error, please contact the sender
> > > immediately
> > > > and delete it from your system. Thank You.
> > > >
> > >
> >
> > --
> > CONFIDENTIALITY NOTICE
> > NOTICE: This message is intended for the use of the individual or entity
> to
> > which it is addressed and may contain information that is confidential,
> > privileged and exempt from disclosure under applicable law. If the reader
> > of this message is not the intended recipient, you are hereby notified
> that
> > any printing, copying, dissemination, distribution, disclosure or
> > forwarding of this communication is strictly prohibited. If you have
> > received this communication in error, please contact the sender
> immediately
> > and delete it from your system. Thank You.
> >
>

Re: [DISCUSS] Migrate from svn to git for source control?

[Karthik Kambatla <ka...@cloudera.com>]

I plan to propose the following in the vote thread. Please advise on more
details to be added and/or concerns you have so we avoid the overhead of
doing this in the vote thread.

1. Migrate from subversion to git for version control
2. Force-push to be disabled on trunk and branch-* branches. Applying
changes from any of trunk/branch-* to any of branch-* should be through
"git cherry-pick -x".
3. Force-push on feature-branches is allowed. Before pulling in a feature,
the feature-branch should be rebased on latest trunk and the changes
applied to trunk through "git rebase --onto" or "git cherry-pick
<commit-range>".
4. The use of tags stay the same after the migration.

On Tue, Aug 5, 2014 at 11:41 PM, Andrew Wang <an...@cloudera.com>
wrote:

> By "merge-based workflow", this is referring to branch development and
> merging? I don't see much issue with allowing a rebase-based workflow if
> we're okay with allowing force-push on feature branches. If anything, the
> next step would be disallowing merge-based workflows and mandating rebases
> for a clean linear history, but it sounds like we'd rather not for now.
>
> Also, to state the obvious, for trunk->branch-2->etc backports, I'd expect
> us to be doing git cherry-picks.
>
> I think it'd be good to disable force-push for the main branches as Arpit
> recommends, we could include that in the VOTE as well.
>
> Thanks,
> Andrew
>
>
> On Tue, Aug 5, 2014 at 9:27 PM, Arpit Agarwal <aa...@hortonworks.com>
> wrote:
>
> > If by very same workflow you mean a merge-based workflow that would be
> fine
> > to call out in the vote proposal.
> >
> > Separately, do we want to disable force push for version branches
> > (branch-x) and point release branches (branch-x.y) in addition to trunk?
> >
> >
> > On Tue, Aug 5, 2014 at 8:18 PM, Alejandro Abdelnur <tu...@gmail.com>
> > wrote:
> >
> > > I would say we can first move to git and keep the very same workflow we
> > > have today, then we can evolve it.
> > >
> > >
> > > On Tue, Aug 5, 2014 at 6:46 PM, Arpit Agarwal <
> aagarwal@hortonworks.com>
> > > wrote:
> > >
> > > > +1 to voting on specific workflow(s).
> > > >
> > > >
> > > > On Tue, Aug 5, 2014 at 5:49 PM, Karthik Kambatla <kasha@cloudera.com
> >
> > > > wrote:
> > > >
> > > > > If we are to start a vote thread, will people prefer a vote thread
> > that
> > > > > includes potential workflows as well?
> > > > >
> > > > >
> > > > > On Tue, Aug 5, 2014 at 5:40 PM, Karthik Kambatla <
> kasha@cloudera.com
> > >
> > > > > wrote:
> > > > >
> > > > > > Thanks for your opinions, everyone. Looks like most people are
> for
> > > the
> > > > > > change and no one is against it. Let me start a vote for this.
> > > > > >
> > > > > >
> > > > > > On Mon, Aug 4, 2014 at 4:44 PM, Tsuyoshi OZAWA <
> > > > ozawa.tsuyoshi@gmail.com
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > >> Thank you for supplementation, Andrew. Yes, we should go step by
> > > step
> > > > > >> and let's discuss review workflows on a another thread.
> > > > > >>
> > > > > >> Thanks,
> > > > > >> - Tsuyoshi
> > > > > >>
> > > > > >> On Tue, Aug 5, 2014 at 8:23 AM, Andrew Wang <
> > > andrew.wang@cloudera.com
> > > > >
> > > > > >> wrote:
> > > > > >> > I think we should take things one step at a time. Switching to
> > git
> > > > > >> > definitely opens up the possibility for better review
> workflows,
> > > but
> > > > > we
> > > > > >> can
> > > > > >> > discuss that on a different thread.
> > > > > >> >
> > > > > >> > A few different people have also mentioned Gerrit, so that'd
> be
> > in
> > > > the
> > > > > >> > running along with Github (and I guess ReviewBoard).
> > > > > >> >
> > > > > >> > Thanks,
> > > > > >> > Andrew
> > > > > >> >
> > > > > >> >
> > > > > >> > On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA <
> > > > > >> ozawa.tsuyoshi@gmail.com>
> > > > > >> > wrote:
> > > > > >> >
> > > > > >> >> Thank you for great suggestion, Karthik. +1(non-binding) to
> use
> > > > git.
> > > > > >> >> I'm also using private git repository.
> > > > > >> >> Additionally, I have one question. Will we accept
> github-based
> > > > > >> >> development like Apache Spark? IHMO, it allow us to leverage
> > > Hadoop
> > > > > >> >> development, because the cost of sending pull request is very
> > low
> > > > and
> > > > > >> >> its review board is great. One concern is that the
> development
> > > > > >> >> workflow can change and it can confuse us. What do you think?
> > > > > >> >>
> > > > > >> >> Thanks,
> > > > > >> >> - Tsuyoshi
> > > > > >> >>
> > > > > >> >> On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla <
> > > > kasha@cloudera.com
> > > > > >
> > > > > >> >> wrote:
> > > > > >> >> > Hi folks,
> > > > > >> >> >
> > > > > >> >> > From what I hear, a lot of devs use the git mirror for
> > > > > >> >> development/reviews
> > > > > >> >> > and use subversion primarily for checking code in. I was
> > > > wondering
> > > > > >> if it
> > > > > >> >> > would make more sense just to move to git. In addition to
> > > > > subjective
> > > > > >> >> liking
> > > > > >> >> > of git, I see the following advantages in our workflow:
> > > > > >> >> >
> > > > > >> >> >    1. Feature branches - it becomes easier to work on them
> > and
> > > > keep
> > > > > >> >> >    rebasing against the latest trunk.
> > > > > >> >> >    2. Cherry-picks between branches automatically ensures
> the
> > > > exact
> > > > > >> same
> > > > > >> >> >    commit message and tracks the lineage as well.
> > > > > >> >> >    3. When cutting new branches and/or updating maven
> > versions
> > > > > etc.,
> > > > > >> it
> > > > > >> >> >    allows doing all the work locally before pushing it to
> the
> > > > main
> > > > > >> >> branch.
> > > > > >> >> >    4. Opens us up to potentially using other code-review
> > tools.
> > > > > >> (Gerrit?)
> > > > > >> >> >    5. It is just more convenient.
> > > > > >> >> >
> > > > > >> >> > I am sure this was brought up before in different
> > capacities. I
> > > > > >> believe
> > > > > >> >> the
> > > > > >> >> > support for git in ASF is healthy now and several
> downstream
> > > > > projects
> > > > > >> >> have
> > > > > >> >> > moved. Again, from what I hear, ASF INFRA folks make the
> > > > migration
> > > > > >> >> process
> > > > > >> >> > fairly easy.
> > > > > >> >> >
> > > > > >> >> > What do you all think?
> > > > > >> >> >
> > > > > >> >> > Thanks
> > > > > >> >> > Karthik
> > > > > >> >>
> > > > > >> >>
> > > > > >> >>
> > > > > >> >> --
> > > > > >> >> - Tsuyoshi
> > > > > >> >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> --
> > > > > >> - Tsuyoshi
> > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > > > --
> > > > CONFIDENTIALITY NOTICE
> > > > NOTICE: This message is intended for the use of the individual or
> > entity
> > > to
> > > > which it is addressed and may contain information that is
> confidential,
> > > > privileged and exempt from disclosure under applicable law. If the
> > reader
> > > > of this message is not the intended recipient, you are hereby
> notified
> > > that
> > > > any printing, copying, dissemination, distribution, disclosure or
> > > > forwarding of this communication is strictly prohibited. If you have
> > > > received this communication in error, please contact the sender
> > > immediately
> > > > and delete it from your system. Thank You.
> > > >
> > >
> >
> > --
> > CONFIDENTIALITY NOTICE
> > NOTICE: This message is intended for the use of the individual or entity
> to
> > which it is addressed and may contain information that is confidential,
> > privileged and exempt from disclosure under applicable law. If the reader
> > of this message is not the intended recipient, you are hereby notified
> that
> > any printing, copying, dissemination, distribution, disclosure or
> > forwarding of this communication is strictly prohibited. If you have
> > received this communication in error, please contact the sender
> immediately
> > and delete it from your system. Thank You.
> >
>

Re: [DISCUSS] Migrate from svn to git for source control?

[Karthik Kambatla <ka...@cloudera.com>]

I plan to propose the following in the vote thread. Please advise on more
details to be added and/or concerns you have so we avoid the overhead of
doing this in the vote thread.

1. Migrate from subversion to git for version control
2. Force-push to be disabled on trunk and branch-* branches. Applying
changes from any of trunk/branch-* to any of branch-* should be through
"git cherry-pick -x".
3. Force-push on feature-branches is allowed. Before pulling in a feature,
the feature-branch should be rebased on latest trunk and the changes
applied to trunk through "git rebase --onto" or "git cherry-pick
<commit-range>".
4. The use of tags stay the same after the migration.

On Tue, Aug 5, 2014 at 11:41 PM, Andrew Wang <an...@cloudera.com>
wrote:

> By "merge-based workflow", this is referring to branch development and
> merging? I don't see much issue with allowing a rebase-based workflow if
> we're okay with allowing force-push on feature branches. If anything, the
> next step would be disallowing merge-based workflows and mandating rebases
> for a clean linear history, but it sounds like we'd rather not for now.
>
> Also, to state the obvious, for trunk->branch-2->etc backports, I'd expect
> us to be doing git cherry-picks.
>
> I think it'd be good to disable force-push for the main branches as Arpit
> recommends, we could include that in the VOTE as well.
>
> Thanks,
> Andrew
>
>
> On Tue, Aug 5, 2014 at 9:27 PM, Arpit Agarwal <aa...@hortonworks.com>
> wrote:
>
> > If by very same workflow you mean a merge-based workflow that would be
> fine
> > to call out in the vote proposal.
> >
> > Separately, do we want to disable force push for version branches
> > (branch-x) and point release branches (branch-x.y) in addition to trunk?
> >
> >
> > On Tue, Aug 5, 2014 at 8:18 PM, Alejandro Abdelnur <tu...@gmail.com>
> > wrote:
> >
> > > I would say we can first move to git and keep the very same workflow we
> > > have today, then we can evolve it.
> > >
> > >
> > > On Tue, Aug 5, 2014 at 6:46 PM, Arpit Agarwal <
> aagarwal@hortonworks.com>
> > > wrote:
> > >
> > > > +1 to voting on specific workflow(s).
> > > >
> > > >
> > > > On Tue, Aug 5, 2014 at 5:49 PM, Karthik Kambatla <kasha@cloudera.com
> >
> > > > wrote:
> > > >
> > > > > If we are to start a vote thread, will people prefer a vote thread
> > that
> > > > > includes potential workflows as well?
> > > > >
> > > > >
> > > > > On Tue, Aug 5, 2014 at 5:40 PM, Karthik Kambatla <
> kasha@cloudera.com
> > >
> > > > > wrote:
> > > > >
> > > > > > Thanks for your opinions, everyone. Looks like most people are
> for
> > > the
> > > > > > change and no one is against it. Let me start a vote for this.
> > > > > >
> > > > > >
> > > > > > On Mon, Aug 4, 2014 at 4:44 PM, Tsuyoshi OZAWA <
> > > > ozawa.tsuyoshi@gmail.com
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > >> Thank you for supplementation, Andrew. Yes, we should go step by
> > > step
> > > > > >> and let's discuss review workflows on a another thread.
> > > > > >>
> > > > > >> Thanks,
> > > > > >> - Tsuyoshi
> > > > > >>
> > > > > >> On Tue, Aug 5, 2014 at 8:23 AM, Andrew Wang <
> > > andrew.wang@cloudera.com
> > > > >
> > > > > >> wrote:
> > > > > >> > I think we should take things one step at a time. Switching to
> > git
> > > > > >> > definitely opens up the possibility for better review
> workflows,
> > > but
> > > > > we
> > > > > >> can
> > > > > >> > discuss that on a different thread.
> > > > > >> >
> > > > > >> > A few different people have also mentioned Gerrit, so that'd
> be
> > in
> > > > the
> > > > > >> > running along with Github (and I guess ReviewBoard).
> > > > > >> >
> > > > > >> > Thanks,
> > > > > >> > Andrew
> > > > > >> >
> > > > > >> >
> > > > > >> > On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA <
> > > > > >> ozawa.tsuyoshi@gmail.com>
> > > > > >> > wrote:
> > > > > >> >
> > > > > >> >> Thank you for great suggestion, Karthik. +1(non-binding) to
> use
> > > > git.
> > > > > >> >> I'm also using private git repository.
> > > > > >> >> Additionally, I have one question. Will we accept
> github-based
> > > > > >> >> development like Apache Spark? IHMO, it allow us to leverage
> > > Hadoop
> > > > > >> >> development, because the cost of sending pull request is very
> > low
> > > > and
> > > > > >> >> its review board is great. One concern is that the
> development
> > > > > >> >> workflow can change and it can confuse us. What do you think?
> > > > > >> >>
> > > > > >> >> Thanks,
> > > > > >> >> - Tsuyoshi
> > > > > >> >>
> > > > > >> >> On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla <
> > > > kasha@cloudera.com
> > > > > >
> > > > > >> >> wrote:
> > > > > >> >> > Hi folks,
> > > > > >> >> >
> > > > > >> >> > From what I hear, a lot of devs use the git mirror for
> > > > > >> >> development/reviews
> > > > > >> >> > and use subversion primarily for checking code in. I was
> > > > wondering
> > > > > >> if it
> > > > > >> >> > would make more sense just to move to git. In addition to
> > > > > subjective
> > > > > >> >> liking
> > > > > >> >> > of git, I see the following advantages in our workflow:
> > > > > >> >> >
> > > > > >> >> >    1. Feature branches - it becomes easier to work on them
> > and
> > > > keep
> > > > > >> >> >    rebasing against the latest trunk.
> > > > > >> >> >    2. Cherry-picks between branches automatically ensures
> the
> > > > exact
> > > > > >> same
> > > > > >> >> >    commit message and tracks the lineage as well.
> > > > > >> >> >    3. When cutting new branches and/or updating maven
> > versions
> > > > > etc.,
> > > > > >> it
> > > > > >> >> >    allows doing all the work locally before pushing it to
> the
> > > > main
> > > > > >> >> branch.
> > > > > >> >> >    4. Opens us up to potentially using other code-review
> > tools.
> > > > > >> (Gerrit?)
> > > > > >> >> >    5. It is just more convenient.
> > > > > >> >> >
> > > > > >> >> > I am sure this was brought up before in different
> > capacities. I
> > > > > >> believe
> > > > > >> >> the
> > > > > >> >> > support for git in ASF is healthy now and several
> downstream
> > > > > projects
> > > > > >> >> have
> > > > > >> >> > moved. Again, from what I hear, ASF INFRA folks make the
> > > > migration
> > > > > >> >> process
> > > > > >> >> > fairly easy.
> > > > > >> >> >
> > > > > >> >> > What do you all think?
> > > > > >> >> >
> > > > > >> >> > Thanks
> > > > > >> >> > Karthik
> > > > > >> >>
> > > > > >> >>
> > > > > >> >>
> > > > > >> >> --
> > > > > >> >> - Tsuyoshi
> > > > > >> >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> --
> > > > > >> - Tsuyoshi
> > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > > > --
> > > > CONFIDENTIALITY NOTICE
> > > > NOTICE: This message is intended for the use of the individual or
> > entity
> > > to
> > > > which it is addressed and may contain information that is
> confidential,
> > > > privileged and exempt from disclosure under applicable law. If the
> > reader
> > > > of this message is not the intended recipient, you are hereby
> notified
> > > that
> > > > any printing, copying, dissemination, distribution, disclosure or
> > > > forwarding of this communication is strictly prohibited. If you have
> > > > received this communication in error, please contact the sender
> > > immediately
> > > > and delete it from your system. Thank You.
> > > >
> > >
> >
> > --
> > CONFIDENTIALITY NOTICE
> > NOTICE: This message is intended for the use of the individual or entity
> to
> > which it is addressed and may contain information that is confidential,
> > privileged and exempt from disclosure under applicable law. If the reader
> > of this message is not the intended recipient, you are hereby notified
> that
> > any printing, copying, dissemination, distribution, disclosure or
> > forwarding of this communication is strictly prohibited. If you have
> > received this communication in error, please contact the sender
> immediately
> > and delete it from your system. Thank You.
> >
>

Re: [DISCUSS] Migrate from svn to git for source control?

[olupot d <ol...@gmail.com>]

I personally use github for most of my projects because it gives me power
over my code versions. I'm a linux user and thats where github takes over..
no offfense but svn is good too but most people know github including the
novice


On Wed, Aug 6, 2014 at 9:41 AM, Andrew Wang <an...@cloudera.com>
wrote:

> By "merge-based workflow", this is referring to branch development and
> merging? I don't see much issue with allowing a rebase-based workflow if
> we're okay with allowing force-push on feature branches. If anything, the
> next step would be disallowing merge-based workflows and mandating rebases
> for a clean linear history, but it sounds like we'd rather not for now.
>
> Also, to state the obvious, for trunk->branch-2->etc backports, I'd expect
> us to be doing git cherry-picks.
>
> I think it'd be good to disable force-push for the main branches as Arpit
> recommends, we could include that in the VOTE as well.
>
> Thanks,
> Andrew
>
>
> On Tue, Aug 5, 2014 at 9:27 PM, Arpit Agarwal <aa...@hortonworks.com>
> wrote:
>
> > If by very same workflow you mean a merge-based workflow that would be
> fine
> > to call out in the vote proposal.
> >
> > Separately, do we want to disable force push for version branches
> > (branch-x) and point release branches (branch-x.y) in addition to trunk?
> >
> >
> > On Tue, Aug 5, 2014 at 8:18 PM, Alejandro Abdelnur <tu...@gmail.com>
> > wrote:
> >
> > > I would say we can first move to git and keep the very same workflow we
> > > have today, then we can evolve it.
> > >
> > >
> > > On Tue, Aug 5, 2014 at 6:46 PM, Arpit Agarwal <
> aagarwal@hortonworks.com>
> > > wrote:
> > >
> > > > +1 to voting on specific workflow(s).
> > > >
> > > >
> > > > On Tue, Aug 5, 2014 at 5:49 PM, Karthik Kambatla <kasha@cloudera.com
> >
> > > > wrote:
> > > >
> > > > > If we are to start a vote thread, will people prefer a vote thread
> > that
> > > > > includes potential workflows as well?
> > > > >
> > > > >
> > > > > On Tue, Aug 5, 2014 at 5:40 PM, Karthik Kambatla <
> kasha@cloudera.com
> > >
> > > > > wrote:
> > > > >
> > > > > > Thanks for your opinions, everyone. Looks like most people are
> for
> > > the
> > > > > > change and no one is against it. Let me start a vote for this.
> > > > > >
> > > > > >
> > > > > > On Mon, Aug 4, 2014 at 4:44 PM, Tsuyoshi OZAWA <
> > > > ozawa.tsuyoshi@gmail.com
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > >> Thank you for supplementation, Andrew. Yes, we should go step by
> > > step
> > > > > >> and let's discuss review workflows on a another thread.
> > > > > >>
> > > > > >> Thanks,
> > > > > >> - Tsuyoshi
> > > > > >>
> > > > > >> On Tue, Aug 5, 2014 at 8:23 AM, Andrew Wang <
> > > andrew.wang@cloudera.com
> > > > >
> > > > > >> wrote:
> > > > > >> > I think we should take things one step at a time. Switching to
> > git
> > > > > >> > definitely opens up the possibility for better review
> workflows,
> > > but
> > > > > we
> > > > > >> can
> > > > > >> > discuss that on a different thread.
> > > > > >> >
> > > > > >> > A few different people have also mentioned Gerrit, so that'd
> be
> > in
> > > > the
> > > > > >> > running along with Github (and I guess ReviewBoard).
> > > > > >> >
> > > > > >> > Thanks,
> > > > > >> > Andrew
> > > > > >> >
> > > > > >> >
> > > > > >> > On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA <
> > > > > >> ozawa.tsuyoshi@gmail.com>
> > > > > >> > wrote:
> > > > > >> >
> > > > > >> >> Thank you for great suggestion, Karthik. +1(non-binding) to
> use
> > > > git.
> > > > > >> >> I'm also using private git repository.
> > > > > >> >> Additionally, I have one question. Will we accept
> github-based
> > > > > >> >> development like Apache Spark? IHMO, it allow us to leverage
> > > Hadoop
> > > > > >> >> development, because the cost of sending pull request is very
> > low
> > > > and
> > > > > >> >> its review board is great. One concern is that the
> development
> > > > > >> >> workflow can change and it can confuse us. What do you think?
> > > > > >> >>
> > > > > >> >> Thanks,
> > > > > >> >> - Tsuyoshi
> > > > > >> >>
> > > > > >> >> On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla <
> > > > kasha@cloudera.com
> > > > > >
> > > > > >> >> wrote:
> > > > > >> >> > Hi folks,
> > > > > >> >> >
> > > > > >> >> > From what I hear, a lot of devs use the git mirror for
> > > > > >> >> development/reviews
> > > > > >> >> > and use subversion primarily for checking code in. I was
> > > > wondering
> > > > > >> if it
> > > > > >> >> > would make more sense just to move to git. In addition to
> > > > > subjective
> > > > > >> >> liking
> > > > > >> >> > of git, I see the following advantages in our workflow:
> > > > > >> >> >
> > > > > >> >> >    1. Feature branches - it becomes easier to work on them
> > and
> > > > keep
> > > > > >> >> >    rebasing against the latest trunk.
> > > > > >> >> >    2. Cherry-picks between branches automatically ensures
> the
> > > > exact
> > > > > >> same
> > > > > >> >> >    commit message and tracks the lineage as well.
> > > > > >> >> >    3. When cutting new branches and/or updating maven
> > versions
> > > > > etc.,
> > > > > >> it
> > > > > >> >> >    allows doing all the work locally before pushing it to
> the
> > > > main
> > > > > >> >> branch.
> > > > > >> >> >    4. Opens us up to potentially using other code-review
> > tools.
> > > > > >> (Gerrit?)
> > > > > >> >> >    5. It is just more convenient.
> > > > > >> >> >
> > > > > >> >> > I am sure this was brought up before in different
> > capacities. I
> > > > > >> believe
> > > > > >> >> the
> > > > > >> >> > support for git in ASF is healthy now and several
> downstream
> > > > > projects
> > > > > >> >> have
> > > > > >> >> > moved. Again, from what I hear, ASF INFRA folks make the
> > > > migration
> > > > > >> >> process
> > > > > >> >> > fairly easy.
> > > > > >> >> >
> > > > > >> >> > What do you all think?
> > > > > >> >> >
> > > > > >> >> > Thanks
> > > > > >> >> > Karthik
> > > > > >> >>
> > > > > >> >>
> > > > > >> >>
> > > > > >> >> --
> > > > > >> >> - Tsuyoshi
> > > > > >> >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> --
> > > > > >> - Tsuyoshi
> > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > > > --
> > > > CONFIDENTIALITY NOTICE
> > > > NOTICE: This message is intended for the use of the individual or
> > entity
> > > to
> > > > which it is addressed and may contain information that is
> confidential,
> > > > privileged and exempt from disclosure under applicable law. If the
> > reader
> > > > of this message is not the intended recipient, you are hereby
> notified
> > > that
> > > > any printing, copying, dissemination, distribution, disclosure or
> > > > forwarding of this communication is strictly prohibited. If you have
> > > > received this communication in error, please contact the sender
> > > immediately
> > > > and delete it from your system. Thank You.
> > > >
> > >
> >
> > --
> > CONFIDENTIALITY NOTICE
> > NOTICE: This message is intended for the use of the individual or entity
> to
> > which it is addressed and may contain information that is confidential,
> > privileged and exempt from disclosure under applicable law. If the reader
> > of this message is not the intended recipient, you are hereby notified
> that
> > any printing, copying, dissemination, distribution, disclosure or
> > forwarding of this communication is strictly prohibited. If you have
> > received this communication in error, please contact the sender
> immediately
> > and delete it from your system. Thank You.
> >
>

Re: [DISCUSS] Migrate from svn to git for source control?

[Karthik Kambatla <ka...@cloudera.com>]

I plan to propose the following in the vote thread. Please advise on more
details to be added and/or concerns you have so we avoid the overhead of
doing this in the vote thread.

1. Migrate from subversion to git for version control
2. Force-push to be disabled on trunk and branch-* branches. Applying
changes from any of trunk/branch-* to any of branch-* should be through
"git cherry-pick -x".
3. Force-push on feature-branches is allowed. Before pulling in a feature,
the feature-branch should be rebased on latest trunk and the changes
applied to trunk through "git rebase --onto" or "git cherry-pick
<commit-range>".
4. The use of tags stay the same after the migration.

On Tue, Aug 5, 2014 at 11:41 PM, Andrew Wang <an...@cloudera.com>
wrote:

> By "merge-based workflow", this is referring to branch development and
> merging? I don't see much issue with allowing a rebase-based workflow if
> we're okay with allowing force-push on feature branches. If anything, the
> next step would be disallowing merge-based workflows and mandating rebases
> for a clean linear history, but it sounds like we'd rather not for now.
>
> Also, to state the obvious, for trunk->branch-2->etc backports, I'd expect
> us to be doing git cherry-picks.
>
> I think it'd be good to disable force-push for the main branches as Arpit
> recommends, we could include that in the VOTE as well.
>
> Thanks,
> Andrew
>
>
> On Tue, Aug 5, 2014 at 9:27 PM, Arpit Agarwal <aa...@hortonworks.com>
> wrote:
>
> > If by very same workflow you mean a merge-based workflow that would be
> fine
> > to call out in the vote proposal.
> >
> > Separately, do we want to disable force push for version branches
> > (branch-x) and point release branches (branch-x.y) in addition to trunk?
> >
> >
> > On Tue, Aug 5, 2014 at 8:18 PM, Alejandro Abdelnur <tu...@gmail.com>
> > wrote:
> >
> > > I would say we can first move to git and keep the very same workflow we
> > > have today, then we can evolve it.
> > >
> > >
> > > On Tue, Aug 5, 2014 at 6:46 PM, Arpit Agarwal <
> aagarwal@hortonworks.com>
> > > wrote:
> > >
> > > > +1 to voting on specific workflow(s).
> > > >
> > > >
> > > > On Tue, Aug 5, 2014 at 5:49 PM, Karthik Kambatla <kasha@cloudera.com
> >
> > > > wrote:
> > > >
> > > > > If we are to start a vote thread, will people prefer a vote thread
> > that
> > > > > includes potential workflows as well?
> > > > >
> > > > >
> > > > > On Tue, Aug 5, 2014 at 5:40 PM, Karthik Kambatla <
> kasha@cloudera.com
> > >
> > > > > wrote:
> > > > >
> > > > > > Thanks for your opinions, everyone. Looks like most people are
> for
> > > the
> > > > > > change and no one is against it. Let me start a vote for this.
> > > > > >
> > > > > >
> > > > > > On Mon, Aug 4, 2014 at 4:44 PM, Tsuyoshi OZAWA <
> > > > ozawa.tsuyoshi@gmail.com
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > >> Thank you for supplementation, Andrew. Yes, we should go step by
> > > step
> > > > > >> and let's discuss review workflows on a another thread.
> > > > > >>
> > > > > >> Thanks,
> > > > > >> - Tsuyoshi
> > > > > >>
> > > > > >> On Tue, Aug 5, 2014 at 8:23 AM, Andrew Wang <
> > > andrew.wang@cloudera.com
> > > > >
> > > > > >> wrote:
> > > > > >> > I think we should take things one step at a time. Switching to
> > git
> > > > > >> > definitely opens up the possibility for better review
> workflows,
> > > but
> > > > > we
> > > > > >> can
> > > > > >> > discuss that on a different thread.
> > > > > >> >
> > > > > >> > A few different people have also mentioned Gerrit, so that'd
> be
> > in
> > > > the
> > > > > >> > running along with Github (and I guess ReviewBoard).
> > > > > >> >
> > > > > >> > Thanks,
> > > > > >> > Andrew
> > > > > >> >
> > > > > >> >
> > > > > >> > On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA <
> > > > > >> ozawa.tsuyoshi@gmail.com>
> > > > > >> > wrote:
> > > > > >> >
> > > > > >> >> Thank you for great suggestion, Karthik. +1(non-binding) to
> use
> > > > git.
> > > > > >> >> I'm also using private git repository.
> > > > > >> >> Additionally, I have one question. Will we accept
> github-based
> > > > > >> >> development like Apache Spark? IHMO, it allow us to leverage
> > > Hadoop
> > > > > >> >> development, because the cost of sending pull request is very
> > low
> > > > and
> > > > > >> >> its review board is great. One concern is that the
> development
> > > > > >> >> workflow can change and it can confuse us. What do you think?
> > > > > >> >>
> > > > > >> >> Thanks,
> > > > > >> >> - Tsuyoshi
> > > > > >> >>
> > > > > >> >> On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla <
> > > > kasha@cloudera.com
> > > > > >
> > > > > >> >> wrote:
> > > > > >> >> > Hi folks,
> > > > > >> >> >
> > > > > >> >> > From what I hear, a lot of devs use the git mirror for
> > > > > >> >> development/reviews
> > > > > >> >> > and use subversion primarily for checking code in. I was
> > > > wondering
> > > > > >> if it
> > > > > >> >> > would make more sense just to move to git. In addition to
> > > > > subjective
> > > > > >> >> liking
> > > > > >> >> > of git, I see the following advantages in our workflow:
> > > > > >> >> >
> > > > > >> >> >    1. Feature branches - it becomes easier to work on them
> > and
> > > > keep
> > > > > >> >> >    rebasing against the latest trunk.
> > > > > >> >> >    2. Cherry-picks between branches automatically ensures
> the
> > > > exact
> > > > > >> same
> > > > > >> >> >    commit message and tracks the lineage as well.
> > > > > >> >> >    3. When cutting new branches and/or updating maven
> > versions
> > > > > etc.,
> > > > > >> it
> > > > > >> >> >    allows doing all the work locally before pushing it to
> the
> > > > main
> > > > > >> >> branch.
> > > > > >> >> >    4. Opens us up to potentially using other code-review
> > tools.
> > > > > >> (Gerrit?)
> > > > > >> >> >    5. It is just more convenient.
> > > > > >> >> >
> > > > > >> >> > I am sure this was brought up before in different
> > capacities. I
> > > > > >> believe
> > > > > >> >> the
> > > > > >> >> > support for git in ASF is healthy now and several
> downstream
> > > > > projects
> > > > > >> >> have
> > > > > >> >> > moved. Again, from what I hear, ASF INFRA folks make the
> > > > migration
> > > > > >> >> process
> > > > > >> >> > fairly easy.
> > > > > >> >> >
> > > > > >> >> > What do you all think?
> > > > > >> >> >
> > > > > >> >> > Thanks
> > > > > >> >> > Karthik
> > > > > >> >>
> > > > > >> >>
> > > > > >> >>
> > > > > >> >> --
> > > > > >> >> - Tsuyoshi
> > > > > >> >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> --
> > > > > >> - Tsuyoshi
> > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > > > --
> > > > CONFIDENTIALITY NOTICE
> > > > NOTICE: This message is intended for the use of the individual or
> > entity
> > > to
> > > > which it is addressed and may contain information that is
> confidential,
> > > > privileged and exempt from disclosure under applicable law. If the
> > reader
> > > > of this message is not the intended recipient, you are hereby
> notified
> > > that
> > > > any printing, copying, dissemination, distribution, disclosure or
> > > > forwarding of this communication is strictly prohibited. If you have
> > > > received this communication in error, please contact the sender
> > > immediately
> > > > and delete it from your system. Thank You.
> > > >
> > >
> >
> > --
> > CONFIDENTIALITY NOTICE
> > NOTICE: This message is intended for the use of the individual or entity
> to
> > which it is addressed and may contain information that is confidential,
> > privileged and exempt from disclosure under applicable law. If the reader
> > of this message is not the intended recipient, you are hereby notified
> that
> > any printing, copying, dissemination, distribution, disclosure or
> > forwarding of this communication is strictly prohibited. If you have
> > received this communication in error, please contact the sender
> immediately
> > and delete it from your system. Thank You.
> >
>

Re: [DISCUSS] Migrate from svn to git for source control?

[Andrew Wang <an...@cloudera.com>]

By "merge-based workflow", this is referring to branch development and
merging? I don't see much issue with allowing a rebase-based workflow if
we're okay with allowing force-push on feature branches. If anything, the
next step would be disallowing merge-based workflows and mandating rebases
for a clean linear history, but it sounds like we'd rather not for now.

Also, to state the obvious, for trunk->branch-2->etc backports, I'd expect
us to be doing git cherry-picks.

I think it'd be good to disable force-push for the main branches as Arpit
recommends, we could include that in the VOTE as well.

Thanks,
Andrew


On Tue, Aug 5, 2014 at 9:27 PM, Arpit Agarwal <aa...@hortonworks.com>
wrote:

> If by very same workflow you mean a merge-based workflow that would be fine
> to call out in the vote proposal.
>
> Separately, do we want to disable force push for version branches
> (branch-x) and point release branches (branch-x.y) in addition to trunk?
>
>
> On Tue, Aug 5, 2014 at 8:18 PM, Alejandro Abdelnur <tu...@gmail.com>
> wrote:
>
> > I would say we can first move to git and keep the very same workflow we
> > have today, then we can evolve it.
> >
> >
> > On Tue, Aug 5, 2014 at 6:46 PM, Arpit Agarwal <aa...@hortonworks.com>
> > wrote:
> >
> > > +1 to voting on specific workflow(s).
> > >
> > >
> > > On Tue, Aug 5, 2014 at 5:49 PM, Karthik Kambatla <ka...@cloudera.com>
> > > wrote:
> > >
> > > > If we are to start a vote thread, will people prefer a vote thread
> that
> > > > includes potential workflows as well?
> > > >
> > > >
> > > > On Tue, Aug 5, 2014 at 5:40 PM, Karthik Kambatla <kasha@cloudera.com
> >
> > > > wrote:
> > > >
> > > > > Thanks for your opinions, everyone. Looks like most people are for
> > the
> > > > > change and no one is against it. Let me start a vote for this.
> > > > >
> > > > >
> > > > > On Mon, Aug 4, 2014 at 4:44 PM, Tsuyoshi OZAWA <
> > > ozawa.tsuyoshi@gmail.com
> > > > >
> > > > > wrote:
> > > > >
> > > > >> Thank you for supplementation, Andrew. Yes, we should go step by
> > step
> > > > >> and let's discuss review workflows on a another thread.
> > > > >>
> > > > >> Thanks,
> > > > >> - Tsuyoshi
> > > > >>
> > > > >> On Tue, Aug 5, 2014 at 8:23 AM, Andrew Wang <
> > andrew.wang@cloudera.com
> > > >
> > > > >> wrote:
> > > > >> > I think we should take things one step at a time. Switching to
> git
> > > > >> > definitely opens up the possibility for better review workflows,
> > but
> > > > we
> > > > >> can
> > > > >> > discuss that on a different thread.
> > > > >> >
> > > > >> > A few different people have also mentioned Gerrit, so that'd be
> in
> > > the
> > > > >> > running along with Github (and I guess ReviewBoard).
> > > > >> >
> > > > >> > Thanks,
> > > > >> > Andrew
> > > > >> >
> > > > >> >
> > > > >> > On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA <
> > > > >> ozawa.tsuyoshi@gmail.com>
> > > > >> > wrote:
> > > > >> >
> > > > >> >> Thank you for great suggestion, Karthik. +1(non-binding) to use
> > > git.
> > > > >> >> I'm also using private git repository.
> > > > >> >> Additionally, I have one question. Will we accept github-based
> > > > >> >> development like Apache Spark? IHMO, it allow us to leverage
> > Hadoop
> > > > >> >> development, because the cost of sending pull request is very
> low
> > > and
> > > > >> >> its review board is great. One concern is that the development
> > > > >> >> workflow can change and it can confuse us. What do you think?
> > > > >> >>
> > > > >> >> Thanks,
> > > > >> >> - Tsuyoshi
> > > > >> >>
> > > > >> >> On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla <
> > > kasha@cloudera.com
> > > > >
> > > > >> >> wrote:
> > > > >> >> > Hi folks,
> > > > >> >> >
> > > > >> >> > From what I hear, a lot of devs use the git mirror for
> > > > >> >> development/reviews
> > > > >> >> > and use subversion primarily for checking code in. I was
> > > wondering
> > > > >> if it
> > > > >> >> > would make more sense just to move to git. In addition to
> > > > subjective
> > > > >> >> liking
> > > > >> >> > of git, I see the following advantages in our workflow:
> > > > >> >> >
> > > > >> >> >    1. Feature branches - it becomes easier to work on them
> and
> > > keep
> > > > >> >> >    rebasing against the latest trunk.
> > > > >> >> >    2. Cherry-picks between branches automatically ensures the
> > > exact
> > > > >> same
> > > > >> >> >    commit message and tracks the lineage as well.
> > > > >> >> >    3. When cutting new branches and/or updating maven
> versions
> > > > etc.,
> > > > >> it
> > > > >> >> >    allows doing all the work locally before pushing it to the
> > > main
> > > > >> >> branch.
> > > > >> >> >    4. Opens us up to potentially using other code-review
> tools.
> > > > >> (Gerrit?)
> > > > >> >> >    5. It is just more convenient.
> > > > >> >> >
> > > > >> >> > I am sure this was brought up before in different
> capacities. I
> > > > >> believe
> > > > >> >> the
> > > > >> >> > support for git in ASF is healthy now and several downstream
> > > > projects
> > > > >> >> have
> > > > >> >> > moved. Again, from what I hear, ASF INFRA folks make the
> > > migration
> > > > >> >> process
> > > > >> >> > fairly easy.
> > > > >> >> >
> > > > >> >> > What do you all think?
> > > > >> >> >
> > > > >> >> > Thanks
> > > > >> >> > Karthik
> > > > >> >>
> > > > >> >>
> > > > >> >>
> > > > >> >> --
> > > > >> >> - Tsuyoshi
> > > > >> >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> --
> > > > >> - Tsuyoshi
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> > > --
> > > CONFIDENTIALITY NOTICE
> > > NOTICE: This message is intended for the use of the individual or
> entity
> > to
> > > which it is addressed and may contain information that is confidential,
> > > privileged and exempt from disclosure under applicable law. If the
> reader
> > > of this message is not the intended recipient, you are hereby notified
> > that
> > > any printing, copying, dissemination, distribution, disclosure or
> > > forwarding of this communication is strictly prohibited. If you have
> > > received this communication in error, please contact the sender
> > immediately
> > > and delete it from your system. Thank You.
> > >
> >
>
> --
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
>

Re: [DISCUSS] Migrate from svn to git for source control?

[Andrew Wang <an...@cloudera.com>]

By "merge-based workflow", this is referring to branch development and
merging? I don't see much issue with allowing a rebase-based workflow if
we're okay with allowing force-push on feature branches. If anything, the
next step would be disallowing merge-based workflows and mandating rebases
for a clean linear history, but it sounds like we'd rather not for now.

Also, to state the obvious, for trunk->branch-2->etc backports, I'd expect
us to be doing git cherry-picks.

I think it'd be good to disable force-push for the main branches as Arpit
recommends, we could include that in the VOTE as well.

Thanks,
Andrew


On Tue, Aug 5, 2014 at 9:27 PM, Arpit Agarwal <aa...@hortonworks.com>
wrote:

> If by very same workflow you mean a merge-based workflow that would be fine
> to call out in the vote proposal.
>
> Separately, do we want to disable force push for version branches
> (branch-x) and point release branches (branch-x.y) in addition to trunk?
>
>
> On Tue, Aug 5, 2014 at 8:18 PM, Alejandro Abdelnur <tu...@gmail.com>
> wrote:
>
> > I would say we can first move to git and keep the very same workflow we
> > have today, then we can evolve it.
> >
> >
> > On Tue, Aug 5, 2014 at 6:46 PM, Arpit Agarwal <aa...@hortonworks.com>
> > wrote:
> >
> > > +1 to voting on specific workflow(s).
> > >
> > >
> > > On Tue, Aug 5, 2014 at 5:49 PM, Karthik Kambatla <ka...@cloudera.com>
> > > wrote:
> > >
> > > > If we are to start a vote thread, will people prefer a vote thread
> that
> > > > includes potential workflows as well?
> > > >
> > > >
> > > > On Tue, Aug 5, 2014 at 5:40 PM, Karthik Kambatla <kasha@cloudera.com
> >
> > > > wrote:
> > > >
> > > > > Thanks for your opinions, everyone. Looks like most people are for
> > the
> > > > > change and no one is against it. Let me start a vote for this.
> > > > >
> > > > >
> > > > > On Mon, Aug 4, 2014 at 4:44 PM, Tsuyoshi OZAWA <
> > > ozawa.tsuyoshi@gmail.com
> > > > >
> > > > > wrote:
> > > > >
> > > > >> Thank you for supplementation, Andrew. Yes, we should go step by
> > step
> > > > >> and let's discuss review workflows on a another thread.
> > > > >>
> > > > >> Thanks,
> > > > >> - Tsuyoshi
> > > > >>
> > > > >> On Tue, Aug 5, 2014 at 8:23 AM, Andrew Wang <
> > andrew.wang@cloudera.com
> > > >
> > > > >> wrote:
> > > > >> > I think we should take things one step at a time. Switching to
> git
> > > > >> > definitely opens up the possibility for better review workflows,
> > but
> > > > we
> > > > >> can
> > > > >> > discuss that on a different thread.
> > > > >> >
> > > > >> > A few different people have also mentioned Gerrit, so that'd be
> in
> > > the
> > > > >> > running along with Github (and I guess ReviewBoard).
> > > > >> >
> > > > >> > Thanks,
> > > > >> > Andrew
> > > > >> >
> > > > >> >
> > > > >> > On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA <
> > > > >> ozawa.tsuyoshi@gmail.com>
> > > > >> > wrote:
> > > > >> >
> > > > >> >> Thank you for great suggestion, Karthik. +1(non-binding) to use
> > > git.
> > > > >> >> I'm also using private git repository.
> > > > >> >> Additionally, I have one question. Will we accept github-based
> > > > >> >> development like Apache Spark? IHMO, it allow us to leverage
> > Hadoop
> > > > >> >> development, because the cost of sending pull request is very
> low
> > > and
> > > > >> >> its review board is great. One concern is that the development
> > > > >> >> workflow can change and it can confuse us. What do you think?
> > > > >> >>
> > > > >> >> Thanks,
> > > > >> >> - Tsuyoshi
> > > > >> >>
> > > > >> >> On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla <
> > > kasha@cloudera.com
> > > > >
> > > > >> >> wrote:
> > > > >> >> > Hi folks,
> > > > >> >> >
> > > > >> >> > From what I hear, a lot of devs use the git mirror for
> > > > >> >> development/reviews
> > > > >> >> > and use subversion primarily for checking code in. I was
> > > wondering
> > > > >> if it
> > > > >> >> > would make more sense just to move to git. In addition to
> > > > subjective
> > > > >> >> liking
> > > > >> >> > of git, I see the following advantages in our workflow:
> > > > >> >> >
> > > > >> >> >    1. Feature branches - it becomes easier to work on them
> and
> > > keep
> > > > >> >> >    rebasing against the latest trunk.
> > > > >> >> >    2. Cherry-picks between branches automatically ensures the
> > > exact
> > > > >> same
> > > > >> >> >    commit message and tracks the lineage as well.
> > > > >> >> >    3. When cutting new branches and/or updating maven
> versions
> > > > etc.,
> > > > >> it
> > > > >> >> >    allows doing all the work locally before pushing it to the
> > > main
> > > > >> >> branch.
> > > > >> >> >    4. Opens us up to potentially using other code-review
> tools.
> > > > >> (Gerrit?)
> > > > >> >> >    5. It is just more convenient.
> > > > >> >> >
> > > > >> >> > I am sure this was brought up before in different
> capacities. I
> > > > >> believe
> > > > >> >> the
> > > > >> >> > support for git in ASF is healthy now and several downstream
> > > > projects
> > > > >> >> have
> > > > >> >> > moved. Again, from what I hear, ASF INFRA folks make the
> > > migration
> > > > >> >> process
> > > > >> >> > fairly easy.
> > > > >> >> >
> > > > >> >> > What do you all think?
> > > > >> >> >
> > > > >> >> > Thanks
> > > > >> >> > Karthik
> > > > >> >>
> > > > >> >>
> > > > >> >>
> > > > >> >> --
> > > > >> >> - Tsuyoshi
> > > > >> >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> --
> > > > >> - Tsuyoshi
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> > > --
> > > CONFIDENTIALITY NOTICE
> > > NOTICE: This message is intended for the use of the individual or
> entity
> > to
> > > which it is addressed and may contain information that is confidential,
> > > privileged and exempt from disclosure under applicable law. If the
> reader
> > > of this message is not the intended recipient, you are hereby notified
> > that
> > > any printing, copying, dissemination, distribution, disclosure or
> > > forwarding of this communication is strictly prohibited. If you have
> > > received this communication in error, please contact the sender
> > immediately
> > > and delete it from your system. Thank You.
> > >
> >
>
> --
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
>

Re: [DISCUSS] Migrate from svn to git for source control?

[Andrew Wang <an...@cloudera.com>]

By "merge-based workflow", this is referring to branch development and
merging? I don't see much issue with allowing a rebase-based workflow if
we're okay with allowing force-push on feature branches. If anything, the
next step would be disallowing merge-based workflows and mandating rebases
for a clean linear history, but it sounds like we'd rather not for now.

Also, to state the obvious, for trunk->branch-2->etc backports, I'd expect
us to be doing git cherry-picks.

I think it'd be good to disable force-push for the main branches as Arpit
recommends, we could include that in the VOTE as well.

Thanks,
Andrew


On Tue, Aug 5, 2014 at 9:27 PM, Arpit Agarwal <aa...@hortonworks.com>
wrote:

> If by very same workflow you mean a merge-based workflow that would be fine
> to call out in the vote proposal.
>
> Separately, do we want to disable force push for version branches
> (branch-x) and point release branches (branch-x.y) in addition to trunk?
>
>
> On Tue, Aug 5, 2014 at 8:18 PM, Alejandro Abdelnur <tu...@gmail.com>
> wrote:
>
> > I would say we can first move to git and keep the very same workflow we
> > have today, then we can evolve it.
> >
> >
> > On Tue, Aug 5, 2014 at 6:46 PM, Arpit Agarwal <aa...@hortonworks.com>
> > wrote:
> >
> > > +1 to voting on specific workflow(s).
> > >
> > >
> > > On Tue, Aug 5, 2014 at 5:49 PM, Karthik Kambatla <ka...@cloudera.com>
> > > wrote:
> > >
> > > > If we are to start a vote thread, will people prefer a vote thread
> that
> > > > includes potential workflows as well?
> > > >
> > > >
> > > > On Tue, Aug 5, 2014 at 5:40 PM, Karthik Kambatla <kasha@cloudera.com
> >
> > > > wrote:
> > > >
> > > > > Thanks for your opinions, everyone. Looks like most people are for
> > the
> > > > > change and no one is against it. Let me start a vote for this.
> > > > >
> > > > >
> > > > > On Mon, Aug 4, 2014 at 4:44 PM, Tsuyoshi OZAWA <
> > > ozawa.tsuyoshi@gmail.com
> > > > >
> > > > > wrote:
> > > > >
> > > > >> Thank you for supplementation, Andrew. Yes, we should go step by
> > step
> > > > >> and let's discuss review workflows on a another thread.
> > > > >>
> > > > >> Thanks,
> > > > >> - Tsuyoshi
> > > > >>
> > > > >> On Tue, Aug 5, 2014 at 8:23 AM, Andrew Wang <
> > andrew.wang@cloudera.com
> > > >
> > > > >> wrote:
> > > > >> > I think we should take things one step at a time. Switching to
> git
> > > > >> > definitely opens up the possibility for better review workflows,
> > but
> > > > we
> > > > >> can
> > > > >> > discuss that on a different thread.
> > > > >> >
> > > > >> > A few different people have also mentioned Gerrit, so that'd be
> in
> > > the
> > > > >> > running along with Github (and I guess ReviewBoard).
> > > > >> >
> > > > >> > Thanks,
> > > > >> > Andrew
> > > > >> >
> > > > >> >
> > > > >> > On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA <
> > > > >> ozawa.tsuyoshi@gmail.com>
> > > > >> > wrote:
> > > > >> >
> > > > >> >> Thank you for great suggestion, Karthik. +1(non-binding) to use
> > > git.
> > > > >> >> I'm also using private git repository.
> > > > >> >> Additionally, I have one question. Will we accept github-based
> > > > >> >> development like Apache Spark? IHMO, it allow us to leverage
> > Hadoop
> > > > >> >> development, because the cost of sending pull request is very
> low
> > > and
> > > > >> >> its review board is great. One concern is that the development
> > > > >> >> workflow can change and it can confuse us. What do you think?
> > > > >> >>
> > > > >> >> Thanks,
> > > > >> >> - Tsuyoshi
> > > > >> >>
> > > > >> >> On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla <
> > > kasha@cloudera.com
> > > > >
> > > > >> >> wrote:
> > > > >> >> > Hi folks,
> > > > >> >> >
> > > > >> >> > From what I hear, a lot of devs use the git mirror for
> > > > >> >> development/reviews
> > > > >> >> > and use subversion primarily for checking code in. I was
> > > wondering
> > > > >> if it
> > > > >> >> > would make more sense just to move to git. In addition to
> > > > subjective
> > > > >> >> liking
> > > > >> >> > of git, I see the following advantages in our workflow:
> > > > >> >> >
> > > > >> >> >    1. Feature branches - it becomes easier to work on them
> and
> > > keep
> > > > >> >> >    rebasing against the latest trunk.
> > > > >> >> >    2. Cherry-picks between branches automatically ensures the
> > > exact
> > > > >> same
> > > > >> >> >    commit message and tracks the lineage as well.
> > > > >> >> >    3. When cutting new branches and/or updating maven
> versions
> > > > etc.,
> > > > >> it
> > > > >> >> >    allows doing all the work locally before pushing it to the
> > > main
> > > > >> >> branch.
> > > > >> >> >    4. Opens us up to potentially using other code-review
> tools.
> > > > >> (Gerrit?)
> > > > >> >> >    5. It is just more convenient.
> > > > >> >> >
> > > > >> >> > I am sure this was brought up before in different
> capacities. I
> > > > >> believe
> > > > >> >> the
> > > > >> >> > support for git in ASF is healthy now and several downstream
> > > > projects
> > > > >> >> have
> > > > >> >> > moved. Again, from what I hear, ASF INFRA folks make the
> > > migration
> > > > >> >> process
> > > > >> >> > fairly easy.
> > > > >> >> >
> > > > >> >> > What do you all think?
> > > > >> >> >
> > > > >> >> > Thanks
> > > > >> >> > Karthik
> > > > >> >>
> > > > >> >>
> > > > >> >>
> > > > >> >> --
> > > > >> >> - Tsuyoshi
> > > > >> >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> --
> > > > >> - Tsuyoshi
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> > > --
> > > CONFIDENTIALITY NOTICE
> > > NOTICE: This message is intended for the use of the individual or
> entity
> > to
> > > which it is addressed and may contain information that is confidential,
> > > privileged and exempt from disclosure under applicable law. If the
> reader
> > > of this message is not the intended recipient, you are hereby notified
> > that
> > > any printing, copying, dissemination, distribution, disclosure or
> > > forwarding of this communication is strictly prohibited. If you have
> > > received this communication in error, please contact the sender
> > immediately
> > > and delete it from your system. Thank You.
> > >
> >
>
> --
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
>

Re: [DISCUSS] Migrate from svn to git for source control?

[Andrew Wang <an...@cloudera.com>]

By "merge-based workflow", this is referring to branch development and
merging? I don't see much issue with allowing a rebase-based workflow if
we're okay with allowing force-push on feature branches. If anything, the
next step would be disallowing merge-based workflows and mandating rebases
for a clean linear history, but it sounds like we'd rather not for now.

Also, to state the obvious, for trunk->branch-2->etc backports, I'd expect
us to be doing git cherry-picks.

I think it'd be good to disable force-push for the main branches as Arpit
recommends, we could include that in the VOTE as well.

Thanks,
Andrew


On Tue, Aug 5, 2014 at 9:27 PM, Arpit Agarwal <aa...@hortonworks.com>
wrote:

> If by very same workflow you mean a merge-based workflow that would be fine
> to call out in the vote proposal.
>
> Separately, do we want to disable force push for version branches
> (branch-x) and point release branches (branch-x.y) in addition to trunk?
>
>
> On Tue, Aug 5, 2014 at 8:18 PM, Alejandro Abdelnur <tu...@gmail.com>
> wrote:
>
> > I would say we can first move to git and keep the very same workflow we
> > have today, then we can evolve it.
> >
> >
> > On Tue, Aug 5, 2014 at 6:46 PM, Arpit Agarwal <aa...@hortonworks.com>
> > wrote:
> >
> > > +1 to voting on specific workflow(s).
> > >
> > >
> > > On Tue, Aug 5, 2014 at 5:49 PM, Karthik Kambatla <ka...@cloudera.com>
> > > wrote:
> > >
> > > > If we are to start a vote thread, will people prefer a vote thread
> that
> > > > includes potential workflows as well?
> > > >
> > > >
> > > > On Tue, Aug 5, 2014 at 5:40 PM, Karthik Kambatla <kasha@cloudera.com
> >
> > > > wrote:
> > > >
> > > > > Thanks for your opinions, everyone. Looks like most people are for
> > the
> > > > > change and no one is against it. Let me start a vote for this.
> > > > >
> > > > >
> > > > > On Mon, Aug 4, 2014 at 4:44 PM, Tsuyoshi OZAWA <
> > > ozawa.tsuyoshi@gmail.com
> > > > >
> > > > > wrote:
> > > > >
> > > > >> Thank you for supplementation, Andrew. Yes, we should go step by
> > step
> > > > >> and let's discuss review workflows on a another thread.
> > > > >>
> > > > >> Thanks,
> > > > >> - Tsuyoshi
> > > > >>
> > > > >> On Tue, Aug 5, 2014 at 8:23 AM, Andrew Wang <
> > andrew.wang@cloudera.com
> > > >
> > > > >> wrote:
> > > > >> > I think we should take things one step at a time. Switching to
> git
> > > > >> > definitely opens up the possibility for better review workflows,
> > but
> > > > we
> > > > >> can
> > > > >> > discuss that on a different thread.
> > > > >> >
> > > > >> > A few different people have also mentioned Gerrit, so that'd be
> in
> > > the
> > > > >> > running along with Github (and I guess ReviewBoard).
> > > > >> >
> > > > >> > Thanks,
> > > > >> > Andrew
> > > > >> >
> > > > >> >
> > > > >> > On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA <
> > > > >> ozawa.tsuyoshi@gmail.com>
> > > > >> > wrote:
> > > > >> >
> > > > >> >> Thank you for great suggestion, Karthik. +1(non-binding) to use
> > > git.
> > > > >> >> I'm also using private git repository.
> > > > >> >> Additionally, I have one question. Will we accept github-based
> > > > >> >> development like Apache Spark? IHMO, it allow us to leverage
> > Hadoop
> > > > >> >> development, because the cost of sending pull request is very
> low
> > > and
> > > > >> >> its review board is great. One concern is that the development
> > > > >> >> workflow can change and it can confuse us. What do you think?
> > > > >> >>
> > > > >> >> Thanks,
> > > > >> >> - Tsuyoshi
> > > > >> >>
> > > > >> >> On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla <
> > > kasha@cloudera.com
> > > > >
> > > > >> >> wrote:
> > > > >> >> > Hi folks,
> > > > >> >> >
> > > > >> >> > From what I hear, a lot of devs use the git mirror for
> > > > >> >> development/reviews
> > > > >> >> > and use subversion primarily for checking code in. I was
> > > wondering
> > > > >> if it
> > > > >> >> > would make more sense just to move to git. In addition to
> > > > subjective
> > > > >> >> liking
> > > > >> >> > of git, I see the following advantages in our workflow:
> > > > >> >> >
> > > > >> >> >    1. Feature branches - it becomes easier to work on them
> and
> > > keep
> > > > >> >> >    rebasing against the latest trunk.
> > > > >> >> >    2. Cherry-picks between branches automatically ensures the
> > > exact
> > > > >> same
> > > > >> >> >    commit message and tracks the lineage as well.
> > > > >> >> >    3. When cutting new branches and/or updating maven
> versions
> > > > etc.,
> > > > >> it
> > > > >> >> >    allows doing all the work locally before pushing it to the
> > > main
> > > > >> >> branch.
> > > > >> >> >    4. Opens us up to potentially using other code-review
> tools.
> > > > >> (Gerrit?)
> > > > >> >> >    5. It is just more convenient.
> > > > >> >> >
> > > > >> >> > I am sure this was brought up before in different
> capacities. I
> > > > >> believe
> > > > >> >> the
> > > > >> >> > support for git in ASF is healthy now and several downstream
> > > > projects
> > > > >> >> have
> > > > >> >> > moved. Again, from what I hear, ASF INFRA folks make the
> > > migration
> > > > >> >> process
> > > > >> >> > fairly easy.
> > > > >> >> >
> > > > >> >> > What do you all think?
> > > > >> >> >
> > > > >> >> > Thanks
> > > > >> >> > Karthik
> > > > >> >>
> > > > >> >>
> > > > >> >>
> > > > >> >> --
> > > > >> >> - Tsuyoshi
> > > > >> >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> --
> > > > >> - Tsuyoshi
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> > > --
> > > CONFIDENTIALITY NOTICE
> > > NOTICE: This message is intended for the use of the individual or
> entity
> > to
> > > which it is addressed and may contain information that is confidential,
> > > privileged and exempt from disclosure under applicable law. If the
> reader
> > > of this message is not the intended recipient, you are hereby notified
> > that
> > > any printing, copying, dissemination, distribution, disclosure or
> > > forwarding of this communication is strictly prohibited. If you have
> > > received this communication in error, please contact the sender
> > immediately
> > > and delete it from your system. Thank You.
> > >
> >
>
> --
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
>

Re: [DISCUSS] Migrate from svn to git for source control?

[Arpit Agarwal <aa...@hortonworks.com>]

If by very same workflow you mean a merge-based workflow that would be fine
to call out in the vote proposal.

Separately, do we want to disable force push for version branches
(branch-x) and point release branches (branch-x.y) in addition to trunk?


On Tue, Aug 5, 2014 at 8:18 PM, Alejandro Abdelnur <tu...@gmail.com> wrote:

> I would say we can first move to git and keep the very same workflow we
> have today, then we can evolve it.
>
>
> On Tue, Aug 5, 2014 at 6:46 PM, Arpit Agarwal <aa...@hortonworks.com>
> wrote:
>
> > +1 to voting on specific workflow(s).
> >
> >
> > On Tue, Aug 5, 2014 at 5:49 PM, Karthik Kambatla <ka...@cloudera.com>
> > wrote:
> >
> > > If we are to start a vote thread, will people prefer a vote thread that
> > > includes potential workflows as well?
> > >
> > >
> > > On Tue, Aug 5, 2014 at 5:40 PM, Karthik Kambatla <ka...@cloudera.com>
> > > wrote:
> > >
> > > > Thanks for your opinions, everyone. Looks like most people are for
> the
> > > > change and no one is against it. Let me start a vote for this.
> > > >
> > > >
> > > > On Mon, Aug 4, 2014 at 4:44 PM, Tsuyoshi OZAWA <
> > ozawa.tsuyoshi@gmail.com
> > > >
> > > > wrote:
> > > >
> > > >> Thank you for supplementation, Andrew. Yes, we should go step by
> step
> > > >> and let's discuss review workflows on a another thread.
> > > >>
> > > >> Thanks,
> > > >> - Tsuyoshi
> > > >>
> > > >> On Tue, Aug 5, 2014 at 8:23 AM, Andrew Wang <
> andrew.wang@cloudera.com
> > >
> > > >> wrote:
> > > >> > I think we should take things one step at a time. Switching to git
> > > >> > definitely opens up the possibility for better review workflows,
> but
> > > we
> > > >> can
> > > >> > discuss that on a different thread.
> > > >> >
> > > >> > A few different people have also mentioned Gerrit, so that'd be in
> > the
> > > >> > running along with Github (and I guess ReviewBoard).
> > > >> >
> > > >> > Thanks,
> > > >> > Andrew
> > > >> >
> > > >> >
> > > >> > On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA <
> > > >> ozawa.tsuyoshi@gmail.com>
> > > >> > wrote:
> > > >> >
> > > >> >> Thank you for great suggestion, Karthik. +1(non-binding) to use
> > git.
> > > >> >> I'm also using private git repository.
> > > >> >> Additionally, I have one question. Will we accept github-based
> > > >> >> development like Apache Spark? IHMO, it allow us to leverage
> Hadoop
> > > >> >> development, because the cost of sending pull request is very low
> > and
> > > >> >> its review board is great. One concern is that the development
> > > >> >> workflow can change and it can confuse us. What do you think?
> > > >> >>
> > > >> >> Thanks,
> > > >> >> - Tsuyoshi
> > > >> >>
> > > >> >> On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla <
> > kasha@cloudera.com
> > > >
> > > >> >> wrote:
> > > >> >> > Hi folks,
> > > >> >> >
> > > >> >> > From what I hear, a lot of devs use the git mirror for
> > > >> >> development/reviews
> > > >> >> > and use subversion primarily for checking code in. I was
> > wondering
> > > >> if it
> > > >> >> > would make more sense just to move to git. In addition to
> > > subjective
> > > >> >> liking
> > > >> >> > of git, I see the following advantages in our workflow:
> > > >> >> >
> > > >> >> >    1. Feature branches - it becomes easier to work on them and
> > keep
> > > >> >> >    rebasing against the latest trunk.
> > > >> >> >    2. Cherry-picks between branches automatically ensures the
> > exact
> > > >> same
> > > >> >> >    commit message and tracks the lineage as well.
> > > >> >> >    3. When cutting new branches and/or updating maven versions
> > > etc.,
> > > >> it
> > > >> >> >    allows doing all the work locally before pushing it to the
> > main
> > > >> >> branch.
> > > >> >> >    4. Opens us up to potentially using other code-review tools.
> > > >> (Gerrit?)
> > > >> >> >    5. It is just more convenient.
> > > >> >> >
> > > >> >> > I am sure this was brought up before in different capacities. I
> > > >> believe
> > > >> >> the
> > > >> >> > support for git in ASF is healthy now and several downstream
> > > projects
> > > >> >> have
> > > >> >> > moved. Again, from what I hear, ASF INFRA folks make the
> > migration
> > > >> >> process
> > > >> >> > fairly easy.
> > > >> >> >
> > > >> >> > What do you all think?
> > > >> >> >
> > > >> >> > Thanks
> > > >> >> > Karthik
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >> --
> > > >> >> - Tsuyoshi
> > > >> >>
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> - Tsuyoshi
> > > >>
> > > >
> > > >
> > >
> >
> > --
> > CONFIDENTIALITY NOTICE
> > NOTICE: This message is intended for the use of the individual or entity
> to
> > which it is addressed and may contain information that is confidential,
> > privileged and exempt from disclosure under applicable law. If the reader
> > of this message is not the intended recipient, you are hereby notified
> that
> > any printing, copying, dissemination, distribution, disclosure or
> > forwarding of this communication is strictly prohibited. If you have
> > received this communication in error, please contact the sender
> immediately
> > and delete it from your system. Thank You.
> >
>

-- 
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to 
which it is addressed and may contain information that is confidential, 
privileged and exempt from disclosure under applicable law. If the reader 
of this message is not the intended recipient, you are hereby notified that 
any printing, copying, dissemination, distribution, disclosure or 
forwarding of this communication is strictly prohibited. If you have 
received this communication in error, please contact the sender immediately 
and delete it from your system. Thank You.

Re: [DISCUSS] Migrate from svn to git for source control?

[Arpit Agarwal <aa...@hortonworks.com>]

If by very same workflow you mean a merge-based workflow that would be fine
to call out in the vote proposal.

Separately, do we want to disable force push for version branches
(branch-x) and point release branches (branch-x.y) in addition to trunk?


On Tue, Aug 5, 2014 at 8:18 PM, Alejandro Abdelnur <tu...@gmail.com> wrote:

> I would say we can first move to git and keep the very same workflow we
> have today, then we can evolve it.
>
>
> On Tue, Aug 5, 2014 at 6:46 PM, Arpit Agarwal <aa...@hortonworks.com>
> wrote:
>
> > +1 to voting on specific workflow(s).
> >
> >
> > On Tue, Aug 5, 2014 at 5:49 PM, Karthik Kambatla <ka...@cloudera.com>
> > wrote:
> >
> > > If we are to start a vote thread, will people prefer a vote thread that
> > > includes potential workflows as well?
> > >
> > >
> > > On Tue, Aug 5, 2014 at 5:40 PM, Karthik Kambatla <ka...@cloudera.com>
> > > wrote:
> > >
> > > > Thanks for your opinions, everyone. Looks like most people are for
> the
> > > > change and no one is against it. Let me start a vote for this.
> > > >
> > > >
> > > > On Mon, Aug 4, 2014 at 4:44 PM, Tsuyoshi OZAWA <
> > ozawa.tsuyoshi@gmail.com
> > > >
> > > > wrote:
> > > >
> > > >> Thank you for supplementation, Andrew. Yes, we should go step by
> step
> > > >> and let's discuss review workflows on a another thread.
> > > >>
> > > >> Thanks,
> > > >> - Tsuyoshi
> > > >>
> > > >> On Tue, Aug 5, 2014 at 8:23 AM, Andrew Wang <
> andrew.wang@cloudera.com
> > >
> > > >> wrote:
> > > >> > I think we should take things one step at a time. Switching to git
> > > >> > definitely opens up the possibility for better review workflows,
> but
> > > we
> > > >> can
> > > >> > discuss that on a different thread.
> > > >> >
> > > >> > A few different people have also mentioned Gerrit, so that'd be in
> > the
> > > >> > running along with Github (and I guess ReviewBoard).
> > > >> >
> > > >> > Thanks,
> > > >> > Andrew
> > > >> >
> > > >> >
> > > >> > On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA <
> > > >> ozawa.tsuyoshi@gmail.com>
> > > >> > wrote:
> > > >> >
> > > >> >> Thank you for great suggestion, Karthik. +1(non-binding) to use
> > git.
> > > >> >> I'm also using private git repository.
> > > >> >> Additionally, I have one question. Will we accept github-based
> > > >> >> development like Apache Spark? IHMO, it allow us to leverage
> Hadoop
> > > >> >> development, because the cost of sending pull request is very low
> > and
> > > >> >> its review board is great. One concern is that the development
> > > >> >> workflow can change and it can confuse us. What do you think?
> > > >> >>
> > > >> >> Thanks,
> > > >> >> - Tsuyoshi
> > > >> >>
> > > >> >> On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla <
> > kasha@cloudera.com
> > > >
> > > >> >> wrote:
> > > >> >> > Hi folks,
> > > >> >> >
> > > >> >> > From what I hear, a lot of devs use the git mirror for
> > > >> >> development/reviews
> > > >> >> > and use subversion primarily for checking code in. I was
> > wondering
> > > >> if it
> > > >> >> > would make more sense just to move to git. In addition to
> > > subjective
> > > >> >> liking
> > > >> >> > of git, I see the following advantages in our workflow:
> > > >> >> >
> > > >> >> >    1. Feature branches - it becomes easier to work on them and
> > keep
> > > >> >> >    rebasing against the latest trunk.
> > > >> >> >    2. Cherry-picks between branches automatically ensures the
> > exact
> > > >> same
> > > >> >> >    commit message and tracks the lineage as well.
> > > >> >> >    3. When cutting new branches and/or updating maven versions
> > > etc.,
> > > >> it
> > > >> >> >    allows doing all the work locally before pushing it to the
> > main
> > > >> >> branch.
> > > >> >> >    4. Opens us up to potentially using other code-review tools.
> > > >> (Gerrit?)
> > > >> >> >    5. It is just more convenient.
> > > >> >> >
> > > >> >> > I am sure this was brought up before in different capacities. I
> > > >> believe
> > > >> >> the
> > > >> >> > support for git in ASF is healthy now and several downstream
> > > projects
> > > >> >> have
> > > >> >> > moved. Again, from what I hear, ASF INFRA folks make the
> > migration
> > > >> >> process
> > > >> >> > fairly easy.
> > > >> >> >
> > > >> >> > What do you all think?
> > > >> >> >
> > > >> >> > Thanks
> > > >> >> > Karthik
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >> --
> > > >> >> - Tsuyoshi
> > > >> >>
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> - Tsuyoshi
> > > >>
> > > >
> > > >
> > >
> >
> > --
> > CONFIDENTIALITY NOTICE
> > NOTICE: This message is intended for the use of the individual or entity
> to
> > which it is addressed and may contain information that is confidential,
> > privileged and exempt from disclosure under applicable law. If the reader
> > of this message is not the intended recipient, you are hereby notified
> that
> > any printing, copying, dissemination, distribution, disclosure or
> > forwarding of this communication is strictly prohibited. If you have
> > received this communication in error, please contact the sender
> immediately
> > and delete it from your system. Thank You.
> >
>

-- 
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to 
which it is addressed and may contain information that is confidential, 
privileged and exempt from disclosure under applicable law. If the reader 
of this message is not the intended recipient, you are hereby notified that 
any printing, copying, dissemination, distribution, disclosure or 
forwarding of this communication is strictly prohibited. If you have 
received this communication in error, please contact the sender immediately 
and delete it from your system. Thank You.

Re: [DISCUSS] Migrate from svn to git for source control?

[Arpit Agarwal <aa...@hortonworks.com>]

If by very same workflow you mean a merge-based workflow that would be fine
to call out in the vote proposal.

Separately, do we want to disable force push for version branches
(branch-x) and point release branches (branch-x.y) in addition to trunk?


On Tue, Aug 5, 2014 at 8:18 PM, Alejandro Abdelnur <tu...@gmail.com> wrote:

> I would say we can first move to git and keep the very same workflow we
> have today, then we can evolve it.
>
>
> On Tue, Aug 5, 2014 at 6:46 PM, Arpit Agarwal <aa...@hortonworks.com>
> wrote:
>
> > +1 to voting on specific workflow(s).
> >
> >
> > On Tue, Aug 5, 2014 at 5:49 PM, Karthik Kambatla <ka...@cloudera.com>
> > wrote:
> >
> > > If we are to start a vote thread, will people prefer a vote thread that
> > > includes potential workflows as well?
> > >
> > >
> > > On Tue, Aug 5, 2014 at 5:40 PM, Karthik Kambatla <ka...@cloudera.com>
> > > wrote:
> > >
> > > > Thanks for your opinions, everyone. Looks like most people are for
> the
> > > > change and no one is against it. Let me start a vote for this.
> > > >
> > > >
> > > > On Mon, Aug 4, 2014 at 4:44 PM, Tsuyoshi OZAWA <
> > ozawa.tsuyoshi@gmail.com
> > > >
> > > > wrote:
> > > >
> > > >> Thank you for supplementation, Andrew. Yes, we should go step by
> step
> > > >> and let's discuss review workflows on a another thread.
> > > >>
> > > >> Thanks,
> > > >> - Tsuyoshi
> > > >>
> > > >> On Tue, Aug 5, 2014 at 8:23 AM, Andrew Wang <
> andrew.wang@cloudera.com
> > >
> > > >> wrote:
> > > >> > I think we should take things one step at a time. Switching to git
> > > >> > definitely opens up the possibility for better review workflows,
> but
> > > we
> > > >> can
> > > >> > discuss that on a different thread.
> > > >> >
> > > >> > A few different people have also mentioned Gerrit, so that'd be in
> > the
> > > >> > running along with Github (and I guess ReviewBoard).
> > > >> >
> > > >> > Thanks,
> > > >> > Andrew
> > > >> >
> > > >> >
> > > >> > On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA <
> > > >> ozawa.tsuyoshi@gmail.com>
> > > >> > wrote:
> > > >> >
> > > >> >> Thank you for great suggestion, Karthik. +1(non-binding) to use
> > git.
> > > >> >> I'm also using private git repository.
> > > >> >> Additionally, I have one question. Will we accept github-based
> > > >> >> development like Apache Spark? IHMO, it allow us to leverage
> Hadoop
> > > >> >> development, because the cost of sending pull request is very low
> > and
> > > >> >> its review board is great. One concern is that the development
> > > >> >> workflow can change and it can confuse us. What do you think?
> > > >> >>
> > > >> >> Thanks,
> > > >> >> - Tsuyoshi
> > > >> >>
> > > >> >> On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla <
> > kasha@cloudera.com
> > > >
> > > >> >> wrote:
> > > >> >> > Hi folks,
> > > >> >> >
> > > >> >> > From what I hear, a lot of devs use the git mirror for
> > > >> >> development/reviews
> > > >> >> > and use subversion primarily for checking code in. I was
> > wondering
> > > >> if it
> > > >> >> > would make more sense just to move to git. In addition to
> > > subjective
> > > >> >> liking
> > > >> >> > of git, I see the following advantages in our workflow:
> > > >> >> >
> > > >> >> >    1. Feature branches - it becomes easier to work on them and
> > keep
> > > >> >> >    rebasing against the latest trunk.
> > > >> >> >    2. Cherry-picks between branches automatically ensures the
> > exact
> > > >> same
> > > >> >> >    commit message and tracks the lineage as well.
> > > >> >> >    3. When cutting new branches and/or updating maven versions
> > > etc.,
> > > >> it
> > > >> >> >    allows doing all the work locally before pushing it to the
> > main
> > > >> >> branch.
> > > >> >> >    4. Opens us up to potentially using other code-review tools.
> > > >> (Gerrit?)
> > > >> >> >    5. It is just more convenient.
> > > >> >> >
> > > >> >> > I am sure this was brought up before in different capacities. I
> > > >> believe
> > > >> >> the
> > > >> >> > support for git in ASF is healthy now and several downstream
> > > projects
> > > >> >> have
> > > >> >> > moved. Again, from what I hear, ASF INFRA folks make the
> > migration
> > > >> >> process
> > > >> >> > fairly easy.
> > > >> >> >
> > > >> >> > What do you all think?
> > > >> >> >
> > > >> >> > Thanks
> > > >> >> > Karthik
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >> --
> > > >> >> - Tsuyoshi
> > > >> >>
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> - Tsuyoshi
> > > >>
> > > >
> > > >
> > >
> >
> > --
> > CONFIDENTIALITY NOTICE
> > NOTICE: This message is intended for the use of the individual or entity
> to
> > which it is addressed and may contain information that is confidential,
> > privileged and exempt from disclosure under applicable law. If the reader
> > of this message is not the intended recipient, you are hereby notified
> that
> > any printing, copying, dissemination, distribution, disclosure or
> > forwarding of this communication is strictly prohibited. If you have
> > received this communication in error, please contact the sender
> immediately
> > and delete it from your system. Thank You.
> >
>

-- 
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to 
which it is addressed and may contain information that is confidential, 
privileged and exempt from disclosure under applicable law. If the reader 
of this message is not the intended recipient, you are hereby notified that 
any printing, copying, dissemination, distribution, disclosure or 
forwarding of this communication is strictly prohibited. If you have 
received this communication in error, please contact the sender immediately 
and delete it from your system. Thank You.

Re: [DISCUSS] Migrate from svn to git for source control?

[Arpit Agarwal <aa...@hortonworks.com>]

If by very same workflow you mean a merge-based workflow that would be fine
to call out in the vote proposal.

Separately, do we want to disable force push for version branches
(branch-x) and point release branches (branch-x.y) in addition to trunk?


On Tue, Aug 5, 2014 at 8:18 PM, Alejandro Abdelnur <tu...@gmail.com> wrote:

> I would say we can first move to git and keep the very same workflow we
> have today, then we can evolve it.
>
>
> On Tue, Aug 5, 2014 at 6:46 PM, Arpit Agarwal <aa...@hortonworks.com>
> wrote:
>
> > +1 to voting on specific workflow(s).
> >
> >
> > On Tue, Aug 5, 2014 at 5:49 PM, Karthik Kambatla <ka...@cloudera.com>
> > wrote:
> >
> > > If we are to start a vote thread, will people prefer a vote thread that
> > > includes potential workflows as well?
> > >
> > >
> > > On Tue, Aug 5, 2014 at 5:40 PM, Karthik Kambatla <ka...@cloudera.com>
> > > wrote:
> > >
> > > > Thanks for your opinions, everyone. Looks like most people are for
> the
> > > > change and no one is against it. Let me start a vote for this.
> > > >
> > > >
> > > > On Mon, Aug 4, 2014 at 4:44 PM, Tsuyoshi OZAWA <
> > ozawa.tsuyoshi@gmail.com
> > > >
> > > > wrote:
> > > >
> > > >> Thank you for supplementation, Andrew. Yes, we should go step by
> step
> > > >> and let's discuss review workflows on a another thread.
> > > >>
> > > >> Thanks,
> > > >> - Tsuyoshi
> > > >>
> > > >> On Tue, Aug 5, 2014 at 8:23 AM, Andrew Wang <
> andrew.wang@cloudera.com
> > >
> > > >> wrote:
> > > >> > I think we should take things one step at a time. Switching to git
> > > >> > definitely opens up the possibility for better review workflows,
> but
> > > we
> > > >> can
> > > >> > discuss that on a different thread.
> > > >> >
> > > >> > A few different people have also mentioned Gerrit, so that'd be in
> > the
> > > >> > running along with Github (and I guess ReviewBoard).
> > > >> >
> > > >> > Thanks,
> > > >> > Andrew
> > > >> >
> > > >> >
> > > >> > On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA <
> > > >> ozawa.tsuyoshi@gmail.com>
> > > >> > wrote:
> > > >> >
> > > >> >> Thank you for great suggestion, Karthik. +1(non-binding) to use
> > git.
> > > >> >> I'm also using private git repository.
> > > >> >> Additionally, I have one question. Will we accept github-based
> > > >> >> development like Apache Spark? IHMO, it allow us to leverage
> Hadoop
> > > >> >> development, because the cost of sending pull request is very low
> > and
> > > >> >> its review board is great. One concern is that the development
> > > >> >> workflow can change and it can confuse us. What do you think?
> > > >> >>
> > > >> >> Thanks,
> > > >> >> - Tsuyoshi
> > > >> >>
> > > >> >> On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla <
> > kasha@cloudera.com
> > > >
> > > >> >> wrote:
> > > >> >> > Hi folks,
> > > >> >> >
> > > >> >> > From what I hear, a lot of devs use the git mirror for
> > > >> >> development/reviews
> > > >> >> > and use subversion primarily for checking code in. I was
> > wondering
> > > >> if it
> > > >> >> > would make more sense just to move to git. In addition to
> > > subjective
> > > >> >> liking
> > > >> >> > of git, I see the following advantages in our workflow:
> > > >> >> >
> > > >> >> >    1. Feature branches - it becomes easier to work on them and
> > keep
> > > >> >> >    rebasing against the latest trunk.
> > > >> >> >    2. Cherry-picks between branches automatically ensures the
> > exact
> > > >> same
> > > >> >> >    commit message and tracks the lineage as well.
> > > >> >> >    3. When cutting new branches and/or updating maven versions
> > > etc.,
> > > >> it
> > > >> >> >    allows doing all the work locally before pushing it to the
> > main
> > > >> >> branch.
> > > >> >> >    4. Opens us up to potentially using other code-review tools.
> > > >> (Gerrit?)
> > > >> >> >    5. It is just more convenient.
> > > >> >> >
> > > >> >> > I am sure this was brought up before in different capacities. I
> > > >> believe
> > > >> >> the
> > > >> >> > support for git in ASF is healthy now and several downstream
> > > projects
> > > >> >> have
> > > >> >> > moved. Again, from what I hear, ASF INFRA folks make the
> > migration
> > > >> >> process
> > > >> >> > fairly easy.
> > > >> >> >
> > > >> >> > What do you all think?
> > > >> >> >
> > > >> >> > Thanks
> > > >> >> > Karthik
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >> --
> > > >> >> - Tsuyoshi
> > > >> >>
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> - Tsuyoshi
> > > >>
> > > >
> > > >
> > >
> >
> > --
> > CONFIDENTIALITY NOTICE
> > NOTICE: This message is intended for the use of the individual or entity
> to
> > which it is addressed and may contain information that is confidential,
> > privileged and exempt from disclosure under applicable law. If the reader
> > of this message is not the intended recipient, you are hereby notified
> that
> > any printing, copying, dissemination, distribution, disclosure or
> > forwarding of this communication is strictly prohibited. If you have
> > received this communication in error, please contact the sender
> immediately
> > and delete it from your system. Thank You.
> >
>

-- 
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to 
which it is addressed and may contain information that is confidential, 
privileged and exempt from disclosure under applicable law. If the reader 
of this message is not the intended recipient, you are hereby notified that 
any printing, copying, dissemination, distribution, disclosure or 
forwarding of this communication is strictly prohibited. If you have 
received this communication in error, please contact the sender immediately 
and delete it from your system. Thank You.

Re: [DISCUSS] Migrate from svn to git for source control?

[Alejandro Abdelnur <tu...@gmail.com>]

I would say we can first move to git and keep the very same workflow we
have today, then we can evolve it.


On Tue, Aug 5, 2014 at 6:46 PM, Arpit Agarwal <aa...@hortonworks.com>
wrote:

> +1 to voting on specific workflow(s).
>
>
> On Tue, Aug 5, 2014 at 5:49 PM, Karthik Kambatla <ka...@cloudera.com>
> wrote:
>
> > If we are to start a vote thread, will people prefer a vote thread that
> > includes potential workflows as well?
> >
> >
> > On Tue, Aug 5, 2014 at 5:40 PM, Karthik Kambatla <ka...@cloudera.com>
> > wrote:
> >
> > > Thanks for your opinions, everyone. Looks like most people are for the
> > > change and no one is against it. Let me start a vote for this.
> > >
> > >
> > > On Mon, Aug 4, 2014 at 4:44 PM, Tsuyoshi OZAWA <
> ozawa.tsuyoshi@gmail.com
> > >
> > > wrote:
> > >
> > >> Thank you for supplementation, Andrew. Yes, we should go step by step
> > >> and let's discuss review workflows on a another thread.
> > >>
> > >> Thanks,
> > >> - Tsuyoshi
> > >>
> > >> On Tue, Aug 5, 2014 at 8:23 AM, Andrew Wang <andrew.wang@cloudera.com
> >
> > >> wrote:
> > >> > I think we should take things one step at a time. Switching to git
> > >> > definitely opens up the possibility for better review workflows, but
> > we
> > >> can
> > >> > discuss that on a different thread.
> > >> >
> > >> > A few different people have also mentioned Gerrit, so that'd be in
> the
> > >> > running along with Github (and I guess ReviewBoard).
> > >> >
> > >> > Thanks,
> > >> > Andrew
> > >> >
> > >> >
> > >> > On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA <
> > >> ozawa.tsuyoshi@gmail.com>
> > >> > wrote:
> > >> >
> > >> >> Thank you for great suggestion, Karthik. +1(non-binding) to use
> git.
> > >> >> I'm also using private git repository.
> > >> >> Additionally, I have one question. Will we accept github-based
> > >> >> development like Apache Spark? IHMO, it allow us to leverage Hadoop
> > >> >> development, because the cost of sending pull request is very low
> and
> > >> >> its review board is great. One concern is that the development
> > >> >> workflow can change and it can confuse us. What do you think?
> > >> >>
> > >> >> Thanks,
> > >> >> - Tsuyoshi
> > >> >>
> > >> >> On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla <
> kasha@cloudera.com
> > >
> > >> >> wrote:
> > >> >> > Hi folks,
> > >> >> >
> > >> >> > From what I hear, a lot of devs use the git mirror for
> > >> >> development/reviews
> > >> >> > and use subversion primarily for checking code in. I was
> wondering
> > >> if it
> > >> >> > would make more sense just to move to git. In addition to
> > subjective
> > >> >> liking
> > >> >> > of git, I see the following advantages in our workflow:
> > >> >> >
> > >> >> >    1. Feature branches - it becomes easier to work on them and
> keep
> > >> >> >    rebasing against the latest trunk.
> > >> >> >    2. Cherry-picks between branches automatically ensures the
> exact
> > >> same
> > >> >> >    commit message and tracks the lineage as well.
> > >> >> >    3. When cutting new branches and/or updating maven versions
> > etc.,
> > >> it
> > >> >> >    allows doing all the work locally before pushing it to the
> main
> > >> >> branch.
> > >> >> >    4. Opens us up to potentially using other code-review tools.
> > >> (Gerrit?)
> > >> >> >    5. It is just more convenient.
> > >> >> >
> > >> >> > I am sure this was brought up before in different capacities. I
> > >> believe
> > >> >> the
> > >> >> > support for git in ASF is healthy now and several downstream
> > projects
> > >> >> have
> > >> >> > moved. Again, from what I hear, ASF INFRA folks make the
> migration
> > >> >> process
> > >> >> > fairly easy.
> > >> >> >
> > >> >> > What do you all think?
> > >> >> >
> > >> >> > Thanks
> > >> >> > Karthik
> > >> >>
> > >> >>
> > >> >>
> > >> >> --
> > >> >> - Tsuyoshi
> > >> >>
> > >>
> > >>
> > >>
> > >> --
> > >> - Tsuyoshi
> > >>
> > >
> > >
> >
>
> --
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
>

Re: [DISCUSS] Migrate from svn to git for source control?

[Alejandro Abdelnur <tu...@gmail.com>]

I would say we can first move to git and keep the very same workflow we
have today, then we can evolve it.


On Tue, Aug 5, 2014 at 6:46 PM, Arpit Agarwal <aa...@hortonworks.com>
wrote:

> +1 to voting on specific workflow(s).
>
>
> On Tue, Aug 5, 2014 at 5:49 PM, Karthik Kambatla <ka...@cloudera.com>
> wrote:
>
> > If we are to start a vote thread, will people prefer a vote thread that
> > includes potential workflows as well?
> >
> >
> > On Tue, Aug 5, 2014 at 5:40 PM, Karthik Kambatla <ka...@cloudera.com>
> > wrote:
> >
> > > Thanks for your opinions, everyone. Looks like most people are for the
> > > change and no one is against it. Let me start a vote for this.
> > >
> > >
> > > On Mon, Aug 4, 2014 at 4:44 PM, Tsuyoshi OZAWA <
> ozawa.tsuyoshi@gmail.com
> > >
> > > wrote:
> > >
> > >> Thank you for supplementation, Andrew. Yes, we should go step by step
> > >> and let's discuss review workflows on a another thread.
> > >>
> > >> Thanks,
> > >> - Tsuyoshi
> > >>
> > >> On Tue, Aug 5, 2014 at 8:23 AM, Andrew Wang <andrew.wang@cloudera.com
> >
> > >> wrote:
> > >> > I think we should take things one step at a time. Switching to git
> > >> > definitely opens up the possibility for better review workflows, but
> > we
> > >> can
> > >> > discuss that on a different thread.
> > >> >
> > >> > A few different people have also mentioned Gerrit, so that'd be in
> the
> > >> > running along with Github (and I guess ReviewBoard).
> > >> >
> > >> > Thanks,
> > >> > Andrew
> > >> >
> > >> >
> > >> > On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA <
> > >> ozawa.tsuyoshi@gmail.com>
> > >> > wrote:
> > >> >
> > >> >> Thank you for great suggestion, Karthik. +1(non-binding) to use
> git.
> > >> >> I'm also using private git repository.
> > >> >> Additionally, I have one question. Will we accept github-based
> > >> >> development like Apache Spark? IHMO, it allow us to leverage Hadoop
> > >> >> development, because the cost of sending pull request is very low
> and
> > >> >> its review board is great. One concern is that the development
> > >> >> workflow can change and it can confuse us. What do you think?
> > >> >>
> > >> >> Thanks,
> > >> >> - Tsuyoshi
> > >> >>
> > >> >> On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla <
> kasha@cloudera.com
> > >
> > >> >> wrote:
> > >> >> > Hi folks,
> > >> >> >
> > >> >> > From what I hear, a lot of devs use the git mirror for
> > >> >> development/reviews
> > >> >> > and use subversion primarily for checking code in. I was
> wondering
> > >> if it
> > >> >> > would make more sense just to move to git. In addition to
> > subjective
> > >> >> liking
> > >> >> > of git, I see the following advantages in our workflow:
> > >> >> >
> > >> >> >    1. Feature branches - it becomes easier to work on them and
> keep
> > >> >> >    rebasing against the latest trunk.
> > >> >> >    2. Cherry-picks between branches automatically ensures the
> exact
> > >> same
> > >> >> >    commit message and tracks the lineage as well.
> > >> >> >    3. When cutting new branches and/or updating maven versions
> > etc.,
> > >> it
> > >> >> >    allows doing all the work locally before pushing it to the
> main
> > >> >> branch.
> > >> >> >    4. Opens us up to potentially using other code-review tools.
> > >> (Gerrit?)
> > >> >> >    5. It is just more convenient.
> > >> >> >
> > >> >> > I am sure this was brought up before in different capacities. I
> > >> believe
> > >> >> the
> > >> >> > support for git in ASF is healthy now and several downstream
> > projects
> > >> >> have
> > >> >> > moved. Again, from what I hear, ASF INFRA folks make the
> migration
> > >> >> process
> > >> >> > fairly easy.
> > >> >> >
> > >> >> > What do you all think?
> > >> >> >
> > >> >> > Thanks
> > >> >> > Karthik
> > >> >>
> > >> >>
> > >> >>
> > >> >> --
> > >> >> - Tsuyoshi
> > >> >>
> > >>
> > >>
> > >>
> > >> --
> > >> - Tsuyoshi
> > >>
> > >
> > >
> >
>
> --
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
>

Re: [DISCUSS] Migrate from svn to git for source control?

[Alejandro Abdelnur <tu...@gmail.com>]

I would say we can first move to git and keep the very same workflow we
have today, then we can evolve it.


On Tue, Aug 5, 2014 at 6:46 PM, Arpit Agarwal <aa...@hortonworks.com>
wrote:

> +1 to voting on specific workflow(s).
>
>
> On Tue, Aug 5, 2014 at 5:49 PM, Karthik Kambatla <ka...@cloudera.com>
> wrote:
>
> > If we are to start a vote thread, will people prefer a vote thread that
> > includes potential workflows as well?
> >
> >
> > On Tue, Aug 5, 2014 at 5:40 PM, Karthik Kambatla <ka...@cloudera.com>
> > wrote:
> >
> > > Thanks for your opinions, everyone. Looks like most people are for the
> > > change and no one is against it. Let me start a vote for this.
> > >
> > >
> > > On Mon, Aug 4, 2014 at 4:44 PM, Tsuyoshi OZAWA <
> ozawa.tsuyoshi@gmail.com
> > >
> > > wrote:
> > >
> > >> Thank you for supplementation, Andrew. Yes, we should go step by step
> > >> and let's discuss review workflows on a another thread.
> > >>
> > >> Thanks,
> > >> - Tsuyoshi
> > >>
> > >> On Tue, Aug 5, 2014 at 8:23 AM, Andrew Wang <andrew.wang@cloudera.com
> >
> > >> wrote:
> > >> > I think we should take things one step at a time. Switching to git
> > >> > definitely opens up the possibility for better review workflows, but
> > we
> > >> can
> > >> > discuss that on a different thread.
> > >> >
> > >> > A few different people have also mentioned Gerrit, so that'd be in
> the
> > >> > running along with Github (and I guess ReviewBoard).
> > >> >
> > >> > Thanks,
> > >> > Andrew
> > >> >
> > >> >
> > >> > On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA <
> > >> ozawa.tsuyoshi@gmail.com>
> > >> > wrote:
> > >> >
> > >> >> Thank you for great suggestion, Karthik. +1(non-binding) to use
> git.
> > >> >> I'm also using private git repository.
> > >> >> Additionally, I have one question. Will we accept github-based
> > >> >> development like Apache Spark? IHMO, it allow us to leverage Hadoop
> > >> >> development, because the cost of sending pull request is very low
> and
> > >> >> its review board is great. One concern is that the development
> > >> >> workflow can change and it can confuse us. What do you think?
> > >> >>
> > >> >> Thanks,
> > >> >> - Tsuyoshi
> > >> >>
> > >> >> On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla <
> kasha@cloudera.com
> > >
> > >> >> wrote:
> > >> >> > Hi folks,
> > >> >> >
> > >> >> > From what I hear, a lot of devs use the git mirror for
> > >> >> development/reviews
> > >> >> > and use subversion primarily for checking code in. I was
> wondering
> > >> if it
> > >> >> > would make more sense just to move to git. In addition to
> > subjective
> > >> >> liking
> > >> >> > of git, I see the following advantages in our workflow:
> > >> >> >
> > >> >> >    1. Feature branches - it becomes easier to work on them and
> keep
> > >> >> >    rebasing against the latest trunk.
> > >> >> >    2. Cherry-picks between branches automatically ensures the
> exact
> > >> same
> > >> >> >    commit message and tracks the lineage as well.
> > >> >> >    3. When cutting new branches and/or updating maven versions
> > etc.,
> > >> it
> > >> >> >    allows doing all the work locally before pushing it to the
> main
> > >> >> branch.
> > >> >> >    4. Opens us up to potentially using other code-review tools.
> > >> (Gerrit?)
> > >> >> >    5. It is just more convenient.
> > >> >> >
> > >> >> > I am sure this was brought up before in different capacities. I
> > >> believe
> > >> >> the
> > >> >> > support for git in ASF is healthy now and several downstream
> > projects
> > >> >> have
> > >> >> > moved. Again, from what I hear, ASF INFRA folks make the
> migration
> > >> >> process
> > >> >> > fairly easy.
> > >> >> >
> > >> >> > What do you all think?
> > >> >> >
> > >> >> > Thanks
> > >> >> > Karthik
> > >> >>
> > >> >>
> > >> >>
> > >> >> --
> > >> >> - Tsuyoshi
> > >> >>
> > >>
> > >>
> > >>
> > >> --
> > >> - Tsuyoshi
> > >>
> > >
> > >
> >
>
> --
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
>

Re: [DISCUSS] Migrate from svn to git for source control?

[Alejandro Abdelnur <tu...@gmail.com>]

I would say we can first move to git and keep the very same workflow we
have today, then we can evolve it.


On Tue, Aug 5, 2014 at 6:46 PM, Arpit Agarwal <aa...@hortonworks.com>
wrote:

> +1 to voting on specific workflow(s).
>
>
> On Tue, Aug 5, 2014 at 5:49 PM, Karthik Kambatla <ka...@cloudera.com>
> wrote:
>
> > If we are to start a vote thread, will people prefer a vote thread that
> > includes potential workflows as well?
> >
> >
> > On Tue, Aug 5, 2014 at 5:40 PM, Karthik Kambatla <ka...@cloudera.com>
> > wrote:
> >
> > > Thanks for your opinions, everyone. Looks like most people are for the
> > > change and no one is against it. Let me start a vote for this.
> > >
> > >
> > > On Mon, Aug 4, 2014 at 4:44 PM, Tsuyoshi OZAWA <
> ozawa.tsuyoshi@gmail.com
> > >
> > > wrote:
> > >
> > >> Thank you for supplementation, Andrew. Yes, we should go step by step
> > >> and let's discuss review workflows on a another thread.
> > >>
> > >> Thanks,
> > >> - Tsuyoshi
> > >>
> > >> On Tue, Aug 5, 2014 at 8:23 AM, Andrew Wang <andrew.wang@cloudera.com
> >
> > >> wrote:
> > >> > I think we should take things one step at a time. Switching to git
> > >> > definitely opens up the possibility for better review workflows, but
> > we
> > >> can
> > >> > discuss that on a different thread.
> > >> >
> > >> > A few different people have also mentioned Gerrit, so that'd be in
> the
> > >> > running along with Github (and I guess ReviewBoard).
> > >> >
> > >> > Thanks,
> > >> > Andrew
> > >> >
> > >> >
> > >> > On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA <
> > >> ozawa.tsuyoshi@gmail.com>
> > >> > wrote:
> > >> >
> > >> >> Thank you for great suggestion, Karthik. +1(non-binding) to use
> git.
> > >> >> I'm also using private git repository.
> > >> >> Additionally, I have one question. Will we accept github-based
> > >> >> development like Apache Spark? IHMO, it allow us to leverage Hadoop
> > >> >> development, because the cost of sending pull request is very low
> and
> > >> >> its review board is great. One concern is that the development
> > >> >> workflow can change and it can confuse us. What do you think?
> > >> >>
> > >> >> Thanks,
> > >> >> - Tsuyoshi
> > >> >>
> > >> >> On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla <
> kasha@cloudera.com
> > >
> > >> >> wrote:
> > >> >> > Hi folks,
> > >> >> >
> > >> >> > From what I hear, a lot of devs use the git mirror for
> > >> >> development/reviews
> > >> >> > and use subversion primarily for checking code in. I was
> wondering
> > >> if it
> > >> >> > would make more sense just to move to git. In addition to
> > subjective
> > >> >> liking
> > >> >> > of git, I see the following advantages in our workflow:
> > >> >> >
> > >> >> >    1. Feature branches - it becomes easier to work on them and
> keep
> > >> >> >    rebasing against the latest trunk.
> > >> >> >    2. Cherry-picks between branches automatically ensures the
> exact
> > >> same
> > >> >> >    commit message and tracks the lineage as well.
> > >> >> >    3. When cutting new branches and/or updating maven versions
> > etc.,
> > >> it
> > >> >> >    allows doing all the work locally before pushing it to the
> main
> > >> >> branch.
> > >> >> >    4. Opens us up to potentially using other code-review tools.
> > >> (Gerrit?)
> > >> >> >    5. It is just more convenient.
> > >> >> >
> > >> >> > I am sure this was brought up before in different capacities. I
> > >> believe
> > >> >> the
> > >> >> > support for git in ASF is healthy now and several downstream
> > projects
> > >> >> have
> > >> >> > moved. Again, from what I hear, ASF INFRA folks make the
> migration
> > >> >> process
> > >> >> > fairly easy.
> > >> >> >
> > >> >> > What do you all think?
> > >> >> >
> > >> >> > Thanks
> > >> >> > Karthik
> > >> >>
> > >> >>
> > >> >>
> > >> >> --
> > >> >> - Tsuyoshi
> > >> >>
> > >>
> > >>
> > >>
> > >> --
> > >> - Tsuyoshi
> > >>
> > >
> > >
> >
>
> --
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
>

Re: [DISCUSS] Migrate from svn to git for source control?

[Arpit Agarwal <aa...@hortonworks.com>]

+1 to voting on specific workflow(s).


On Tue, Aug 5, 2014 at 5:49 PM, Karthik Kambatla <ka...@cloudera.com> wrote:

> If we are to start a vote thread, will people prefer a vote thread that
> includes potential workflows as well?
>
>
> On Tue, Aug 5, 2014 at 5:40 PM, Karthik Kambatla <ka...@cloudera.com>
> wrote:
>
> > Thanks for your opinions, everyone. Looks like most people are for the
> > change and no one is against it. Let me start a vote for this.
> >
> >
> > On Mon, Aug 4, 2014 at 4:44 PM, Tsuyoshi OZAWA <ozawa.tsuyoshi@gmail.com
> >
> > wrote:
> >
> >> Thank you for supplementation, Andrew. Yes, we should go step by step
> >> and let's discuss review workflows on a another thread.
> >>
> >> Thanks,
> >> - Tsuyoshi
> >>
> >> On Tue, Aug 5, 2014 at 8:23 AM, Andrew Wang <an...@cloudera.com>
> >> wrote:
> >> > I think we should take things one step at a time. Switching to git
> >> > definitely opens up the possibility for better review workflows, but
> we
> >> can
> >> > discuss that on a different thread.
> >> >
> >> > A few different people have also mentioned Gerrit, so that'd be in the
> >> > running along with Github (and I guess ReviewBoard).
> >> >
> >> > Thanks,
> >> > Andrew
> >> >
> >> >
> >> > On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA <
> >> ozawa.tsuyoshi@gmail.com>
> >> > wrote:
> >> >
> >> >> Thank you for great suggestion, Karthik. +1(non-binding) to use git.
> >> >> I'm also using private git repository.
> >> >> Additionally, I have one question. Will we accept github-based
> >> >> development like Apache Spark? IHMO, it allow us to leverage Hadoop
> >> >> development, because the cost of sending pull request is very low and
> >> >> its review board is great. One concern is that the development
> >> >> workflow can change and it can confuse us. What do you think?
> >> >>
> >> >> Thanks,
> >> >> - Tsuyoshi
> >> >>
> >> >> On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla <kasha@cloudera.com
> >
> >> >> wrote:
> >> >> > Hi folks,
> >> >> >
> >> >> > From what I hear, a lot of devs use the git mirror for
> >> >> development/reviews
> >> >> > and use subversion primarily for checking code in. I was wondering
> >> if it
> >> >> > would make more sense just to move to git. In addition to
> subjective
> >> >> liking
> >> >> > of git, I see the following advantages in our workflow:
> >> >> >
> >> >> >    1. Feature branches - it becomes easier to work on them and keep
> >> >> >    rebasing against the latest trunk.
> >> >> >    2. Cherry-picks between branches automatically ensures the exact
> >> same
> >> >> >    commit message and tracks the lineage as well.
> >> >> >    3. When cutting new branches and/or updating maven versions
> etc.,
> >> it
> >> >> >    allows doing all the work locally before pushing it to the main
> >> >> branch.
> >> >> >    4. Opens us up to potentially using other code-review tools.
> >> (Gerrit?)
> >> >> >    5. It is just more convenient.
> >> >> >
> >> >> > I am sure this was brought up before in different capacities. I
> >> believe
> >> >> the
> >> >> > support for git in ASF is healthy now and several downstream
> projects
> >> >> have
> >> >> > moved. Again, from what I hear, ASF INFRA folks make the migration
> >> >> process
> >> >> > fairly easy.
> >> >> >
> >> >> > What do you all think?
> >> >> >
> >> >> > Thanks
> >> >> > Karthik
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> - Tsuyoshi
> >> >>
> >>
> >>
> >>
> >> --
> >> - Tsuyoshi
> >>
> >
> >
>

-- 
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to 
which it is addressed and may contain information that is confidential, 
privileged and exempt from disclosure under applicable law. If the reader 
of this message is not the intended recipient, you are hereby notified that 
any printing, copying, dissemination, distribution, disclosure or 
forwarding of this communication is strictly prohibited. If you have 
received this communication in error, please contact the sender immediately 
and delete it from your system. Thank You.

Re: [DISCUSS] Migrate from svn to git for source control?

[Arpit Agarwal <aa...@hortonworks.com>]

+1 to voting on specific workflow(s).


On Tue, Aug 5, 2014 at 5:49 PM, Karthik Kambatla <ka...@cloudera.com> wrote:

> If we are to start a vote thread, will people prefer a vote thread that
> includes potential workflows as well?
>
>
> On Tue, Aug 5, 2014 at 5:40 PM, Karthik Kambatla <ka...@cloudera.com>
> wrote:
>
> > Thanks for your opinions, everyone. Looks like most people are for the
> > change and no one is against it. Let me start a vote for this.
> >
> >
> > On Mon, Aug 4, 2014 at 4:44 PM, Tsuyoshi OZAWA <ozawa.tsuyoshi@gmail.com
> >
> > wrote:
> >
> >> Thank you for supplementation, Andrew. Yes, we should go step by step
> >> and let's discuss review workflows on a another thread.
> >>
> >> Thanks,
> >> - Tsuyoshi
> >>
> >> On Tue, Aug 5, 2014 at 8:23 AM, Andrew Wang <an...@cloudera.com>
> >> wrote:
> >> > I think we should take things one step at a time. Switching to git
> >> > definitely opens up the possibility for better review workflows, but
> we
> >> can
> >> > discuss that on a different thread.
> >> >
> >> > A few different people have also mentioned Gerrit, so that'd be in the
> >> > running along with Github (and I guess ReviewBoard).
> >> >
> >> > Thanks,
> >> > Andrew
> >> >
> >> >
> >> > On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA <
> >> ozawa.tsuyoshi@gmail.com>
> >> > wrote:
> >> >
> >> >> Thank you for great suggestion, Karthik. +1(non-binding) to use git.
> >> >> I'm also using private git repository.
> >> >> Additionally, I have one question. Will we accept github-based
> >> >> development like Apache Spark? IHMO, it allow us to leverage Hadoop
> >> >> development, because the cost of sending pull request is very low and
> >> >> its review board is great. One concern is that the development
> >> >> workflow can change and it can confuse us. What do you think?
> >> >>
> >> >> Thanks,
> >> >> - Tsuyoshi
> >> >>
> >> >> On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla <kasha@cloudera.com
> >
> >> >> wrote:
> >> >> > Hi folks,
> >> >> >
> >> >> > From what I hear, a lot of devs use the git mirror for
> >> >> development/reviews
> >> >> > and use subversion primarily for checking code in. I was wondering
> >> if it
> >> >> > would make more sense just to move to git. In addition to
> subjective
> >> >> liking
> >> >> > of git, I see the following advantages in our workflow:
> >> >> >
> >> >> >    1. Feature branches - it becomes easier to work on them and keep
> >> >> >    rebasing against the latest trunk.
> >> >> >    2. Cherry-picks between branches automatically ensures the exact
> >> same
> >> >> >    commit message and tracks the lineage as well.
> >> >> >    3. When cutting new branches and/or updating maven versions
> etc.,
> >> it
> >> >> >    allows doing all the work locally before pushing it to the main
> >> >> branch.
> >> >> >    4. Opens us up to potentially using other code-review tools.
> >> (Gerrit?)
> >> >> >    5. It is just more convenient.
> >> >> >
> >> >> > I am sure this was brought up before in different capacities. I
> >> believe
> >> >> the
> >> >> > support for git in ASF is healthy now and several downstream
> projects
> >> >> have
> >> >> > moved. Again, from what I hear, ASF INFRA folks make the migration
> >> >> process
> >> >> > fairly easy.
> >> >> >
> >> >> > What do you all think?
> >> >> >
> >> >> > Thanks
> >> >> > Karthik
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> - Tsuyoshi
> >> >>
> >>
> >>
> >>
> >> --
> >> - Tsuyoshi
> >>
> >
> >
>

-- 
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to 
which it is addressed and may contain information that is confidential, 
privileged and exempt from disclosure under applicable law. If the reader 
of this message is not the intended recipient, you are hereby notified that 
any printing, copying, dissemination, distribution, disclosure or 
forwarding of this communication is strictly prohibited. If you have 
received this communication in error, please contact the sender immediately 
and delete it from your system. Thank You.

Re: [DISCUSS] Migrate from svn to git for source control?

[Arpit Agarwal <aa...@hortonworks.com>]

+1 to voting on specific workflow(s).


On Tue, Aug 5, 2014 at 5:49 PM, Karthik Kambatla <ka...@cloudera.com> wrote:

> If we are to start a vote thread, will people prefer a vote thread that
> includes potential workflows as well?
>
>
> On Tue, Aug 5, 2014 at 5:40 PM, Karthik Kambatla <ka...@cloudera.com>
> wrote:
>
> > Thanks for your opinions, everyone. Looks like most people are for the
> > change and no one is against it. Let me start a vote for this.
> >
> >
> > On Mon, Aug 4, 2014 at 4:44 PM, Tsuyoshi OZAWA <ozawa.tsuyoshi@gmail.com
> >
> > wrote:
> >
> >> Thank you for supplementation, Andrew. Yes, we should go step by step
> >> and let's discuss review workflows on a another thread.
> >>
> >> Thanks,
> >> - Tsuyoshi
> >>
> >> On Tue, Aug 5, 2014 at 8:23 AM, Andrew Wang <an...@cloudera.com>
> >> wrote:
> >> > I think we should take things one step at a time. Switching to git
> >> > definitely opens up the possibility for better review workflows, but
> we
> >> can
> >> > discuss that on a different thread.
> >> >
> >> > A few different people have also mentioned Gerrit, so that'd be in the
> >> > running along with Github (and I guess ReviewBoard).
> >> >
> >> > Thanks,
> >> > Andrew
> >> >
> >> >
> >> > On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA <
> >> ozawa.tsuyoshi@gmail.com>
> >> > wrote:
> >> >
> >> >> Thank you for great suggestion, Karthik. +1(non-binding) to use git.
> >> >> I'm also using private git repository.
> >> >> Additionally, I have one question. Will we accept github-based
> >> >> development like Apache Spark? IHMO, it allow us to leverage Hadoop
> >> >> development, because the cost of sending pull request is very low and
> >> >> its review board is great. One concern is that the development
> >> >> workflow can change and it can confuse us. What do you think?
> >> >>
> >> >> Thanks,
> >> >> - Tsuyoshi
> >> >>
> >> >> On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla <kasha@cloudera.com
> >
> >> >> wrote:
> >> >> > Hi folks,
> >> >> >
> >> >> > From what I hear, a lot of devs use the git mirror for
> >> >> development/reviews
> >> >> > and use subversion primarily for checking code in. I was wondering
> >> if it
> >> >> > would make more sense just to move to git. In addition to
> subjective
> >> >> liking
> >> >> > of git, I see the following advantages in our workflow:
> >> >> >
> >> >> >    1. Feature branches - it becomes easier to work on them and keep
> >> >> >    rebasing against the latest trunk.
> >> >> >    2. Cherry-picks between branches automatically ensures the exact
> >> same
> >> >> >    commit message and tracks the lineage as well.
> >> >> >    3. When cutting new branches and/or updating maven versions
> etc.,
> >> it
> >> >> >    allows doing all the work locally before pushing it to the main
> >> >> branch.
> >> >> >    4. Opens us up to potentially using other code-review tools.
> >> (Gerrit?)
> >> >> >    5. It is just more convenient.
> >> >> >
> >> >> > I am sure this was brought up before in different capacities. I
> >> believe
> >> >> the
> >> >> > support for git in ASF is healthy now and several downstream
> projects
> >> >> have
> >> >> > moved. Again, from what I hear, ASF INFRA folks make the migration
> >> >> process
> >> >> > fairly easy.
> >> >> >
> >> >> > What do you all think?
> >> >> >
> >> >> > Thanks
> >> >> > Karthik
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> - Tsuyoshi
> >> >>
> >>
> >>
> >>
> >> --
> >> - Tsuyoshi
> >>
> >
> >
>

-- 
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to 
which it is addressed and may contain information that is confidential, 
privileged and exempt from disclosure under applicable law. If the reader 
of this message is not the intended recipient, you are hereby notified that 
any printing, copying, dissemination, distribution, disclosure or 
forwarding of this communication is strictly prohibited. If you have 
received this communication in error, please contact the sender immediately 
and delete it from your system. Thank You.

Re: [DISCUSS] Migrate from svn to git for source control?

[Arpit Agarwal <aa...@hortonworks.com>]

+1 to voting on specific workflow(s).


On Tue, Aug 5, 2014 at 5:49 PM, Karthik Kambatla <ka...@cloudera.com> wrote:

> If we are to start a vote thread, will people prefer a vote thread that
> includes potential workflows as well?
>
>
> On Tue, Aug 5, 2014 at 5:40 PM, Karthik Kambatla <ka...@cloudera.com>
> wrote:
>
> > Thanks for your opinions, everyone. Looks like most people are for the
> > change and no one is against it. Let me start a vote for this.
> >
> >
> > On Mon, Aug 4, 2014 at 4:44 PM, Tsuyoshi OZAWA <ozawa.tsuyoshi@gmail.com
> >
> > wrote:
> >
> >> Thank you for supplementation, Andrew. Yes, we should go step by step
> >> and let's discuss review workflows on a another thread.
> >>
> >> Thanks,
> >> - Tsuyoshi
> >>
> >> On Tue, Aug 5, 2014 at 8:23 AM, Andrew Wang <an...@cloudera.com>
> >> wrote:
> >> > I think we should take things one step at a time. Switching to git
> >> > definitely opens up the possibility for better review workflows, but
> we
> >> can
> >> > discuss that on a different thread.
> >> >
> >> > A few different people have also mentioned Gerrit, so that'd be in the
> >> > running along with Github (and I guess ReviewBoard).
> >> >
> >> > Thanks,
> >> > Andrew
> >> >
> >> >
> >> > On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA <
> >> ozawa.tsuyoshi@gmail.com>
> >> > wrote:
> >> >
> >> >> Thank you for great suggestion, Karthik. +1(non-binding) to use git.
> >> >> I'm also using private git repository.
> >> >> Additionally, I have one question. Will we accept github-based
> >> >> development like Apache Spark? IHMO, it allow us to leverage Hadoop
> >> >> development, because the cost of sending pull request is very low and
> >> >> its review board is great. One concern is that the development
> >> >> workflow can change and it can confuse us. What do you think?
> >> >>
> >> >> Thanks,
> >> >> - Tsuyoshi
> >> >>
> >> >> On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla <kasha@cloudera.com
> >
> >> >> wrote:
> >> >> > Hi folks,
> >> >> >
> >> >> > From what I hear, a lot of devs use the git mirror for
> >> >> development/reviews
> >> >> > and use subversion primarily for checking code in. I was wondering
> >> if it
> >> >> > would make more sense just to move to git. In addition to
> subjective
> >> >> liking
> >> >> > of git, I see the following advantages in our workflow:
> >> >> >
> >> >> >    1. Feature branches - it becomes easier to work on them and keep
> >> >> >    rebasing against the latest trunk.
> >> >> >    2. Cherry-picks between branches automatically ensures the exact
> >> same
> >> >> >    commit message and tracks the lineage as well.
> >> >> >    3. When cutting new branches and/or updating maven versions
> etc.,
> >> it
> >> >> >    allows doing all the work locally before pushing it to the main
> >> >> branch.
> >> >> >    4. Opens us up to potentially using other code-review tools.
> >> (Gerrit?)
> >> >> >    5. It is just more convenient.
> >> >> >
> >> >> > I am sure this was brought up before in different capacities. I
> >> believe
> >> >> the
> >> >> > support for git in ASF is healthy now and several downstream
> projects
> >> >> have
> >> >> > moved. Again, from what I hear, ASF INFRA folks make the migration
> >> >> process
> >> >> > fairly easy.
> >> >> >
> >> >> > What do you all think?
> >> >> >
> >> >> > Thanks
> >> >> > Karthik
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> - Tsuyoshi
> >> >>
> >>
> >>
> >>
> >> --
> >> - Tsuyoshi
> >>
> >
> >
>

-- 
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to 
which it is addressed and may contain information that is confidential, 
privileged and exempt from disclosure under applicable law. If the reader 
of this message is not the intended recipient, you are hereby notified that 
any printing, copying, dissemination, distribution, disclosure or 
forwarding of this communication is strictly prohibited. If you have 
received this communication in error, please contact the sender immediately 
and delete it from your system. Thank You.

Re: [DISCUSS] Migrate from svn to git for source control?

[Karthik Kambatla <ka...@cloudera.com>]

If we are to start a vote thread, will people prefer a vote thread that
includes potential workflows as well?


On Tue, Aug 5, 2014 at 5:40 PM, Karthik Kambatla <ka...@cloudera.com> wrote:

> Thanks for your opinions, everyone. Looks like most people are for the
> change and no one is against it. Let me start a vote for this.
>
>
> On Mon, Aug 4, 2014 at 4:44 PM, Tsuyoshi OZAWA <oz...@gmail.com>
> wrote:
>
>> Thank you for supplementation, Andrew. Yes, we should go step by step
>> and let's discuss review workflows on a another thread.
>>
>> Thanks,
>> - Tsuyoshi
>>
>> On Tue, Aug 5, 2014 at 8:23 AM, Andrew Wang <an...@cloudera.com>
>> wrote:
>> > I think we should take things one step at a time. Switching to git
>> > definitely opens up the possibility for better review workflows, but we
>> can
>> > discuss that on a different thread.
>> >
>> > A few different people have also mentioned Gerrit, so that'd be in the
>> > running along with Github (and I guess ReviewBoard).
>> >
>> > Thanks,
>> > Andrew
>> >
>> >
>> > On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA <
>> ozawa.tsuyoshi@gmail.com>
>> > wrote:
>> >
>> >> Thank you for great suggestion, Karthik. +1(non-binding) to use git.
>> >> I'm also using private git repository.
>> >> Additionally, I have one question. Will we accept github-based
>> >> development like Apache Spark? IHMO, it allow us to leverage Hadoop
>> >> development, because the cost of sending pull request is very low and
>> >> its review board is great. One concern is that the development
>> >> workflow can change and it can confuse us. What do you think?
>> >>
>> >> Thanks,
>> >> - Tsuyoshi
>> >>
>> >> On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla <ka...@cloudera.com>
>> >> wrote:
>> >> > Hi folks,
>> >> >
>> >> > From what I hear, a lot of devs use the git mirror for
>> >> development/reviews
>> >> > and use subversion primarily for checking code in. I was wondering
>> if it
>> >> > would make more sense just to move to git. In addition to subjective
>> >> liking
>> >> > of git, I see the following advantages in our workflow:
>> >> >
>> >> >    1. Feature branches - it becomes easier to work on them and keep
>> >> >    rebasing against the latest trunk.
>> >> >    2. Cherry-picks between branches automatically ensures the exact
>> same
>> >> >    commit message and tracks the lineage as well.
>> >> >    3. When cutting new branches and/or updating maven versions etc.,
>> it
>> >> >    allows doing all the work locally before pushing it to the main
>> >> branch.
>> >> >    4. Opens us up to potentially using other code-review tools.
>> (Gerrit?)
>> >> >    5. It is just more convenient.
>> >> >
>> >> > I am sure this was brought up before in different capacities. I
>> believe
>> >> the
>> >> > support for git in ASF is healthy now and several downstream projects
>> >> have
>> >> > moved. Again, from what I hear, ASF INFRA folks make the migration
>> >> process
>> >> > fairly easy.
>> >> >
>> >> > What do you all think?
>> >> >
>> >> > Thanks
>> >> > Karthik
>> >>
>> >>
>> >>
>> >> --
>> >> - Tsuyoshi
>> >>
>>
>>
>>
>> --
>> - Tsuyoshi
>>
>
>

Re: [DISCUSS] Migrate from svn to git for source control?

[Karthik Kambatla <ka...@cloudera.com>]

If we are to start a vote thread, will people prefer a vote thread that
includes potential workflows as well?


On Tue, Aug 5, 2014 at 5:40 PM, Karthik Kambatla <ka...@cloudera.com> wrote:

> Thanks for your opinions, everyone. Looks like most people are for the
> change and no one is against it. Let me start a vote for this.
>
>
> On Mon, Aug 4, 2014 at 4:44 PM, Tsuyoshi OZAWA <oz...@gmail.com>
> wrote:
>
>> Thank you for supplementation, Andrew. Yes, we should go step by step
>> and let's discuss review workflows on a another thread.
>>
>> Thanks,
>> - Tsuyoshi
>>
>> On Tue, Aug 5, 2014 at 8:23 AM, Andrew Wang <an...@cloudera.com>
>> wrote:
>> > I think we should take things one step at a time. Switching to git
>> > definitely opens up the possibility for better review workflows, but we
>> can
>> > discuss that on a different thread.
>> >
>> > A few different people have also mentioned Gerrit, so that'd be in the
>> > running along with Github (and I guess ReviewBoard).
>> >
>> > Thanks,
>> > Andrew
>> >
>> >
>> > On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA <
>> ozawa.tsuyoshi@gmail.com>
>> > wrote:
>> >
>> >> Thank you for great suggestion, Karthik. +1(non-binding) to use git.
>> >> I'm also using private git repository.
>> >> Additionally, I have one question. Will we accept github-based
>> >> development like Apache Spark? IHMO, it allow us to leverage Hadoop
>> >> development, because the cost of sending pull request is very low and
>> >> its review board is great. One concern is that the development
>> >> workflow can change and it can confuse us. What do you think?
>> >>
>> >> Thanks,
>> >> - Tsuyoshi
>> >>
>> >> On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla <ka...@cloudera.com>
>> >> wrote:
>> >> > Hi folks,
>> >> >
>> >> > From what I hear, a lot of devs use the git mirror for
>> >> development/reviews
>> >> > and use subversion primarily for checking code in. I was wondering
>> if it
>> >> > would make more sense just to move to git. In addition to subjective
>> >> liking
>> >> > of git, I see the following advantages in our workflow:
>> >> >
>> >> >    1. Feature branches - it becomes easier to work on them and keep
>> >> >    rebasing against the latest trunk.
>> >> >    2. Cherry-picks between branches automatically ensures the exact
>> same
>> >> >    commit message and tracks the lineage as well.
>> >> >    3. When cutting new branches and/or updating maven versions etc.,
>> it
>> >> >    allows doing all the work locally before pushing it to the main
>> >> branch.
>> >> >    4. Opens us up to potentially using other code-review tools.
>> (Gerrit?)
>> >> >    5. It is just more convenient.
>> >> >
>> >> > I am sure this was brought up before in different capacities. I
>> believe
>> >> the
>> >> > support for git in ASF is healthy now and several downstream projects
>> >> have
>> >> > moved. Again, from what I hear, ASF INFRA folks make the migration
>> >> process
>> >> > fairly easy.
>> >> >
>> >> > What do you all think?
>> >> >
>> >> > Thanks
>> >> > Karthik
>> >>
>> >>
>> >>
>> >> --
>> >> - Tsuyoshi
>> >>
>>
>>
>>
>> --
>> - Tsuyoshi
>>
>
>

Re: [DISCUSS] Migrate from svn to git for source control?

[Karthik Kambatla <ka...@cloudera.com>]

If we are to start a vote thread, will people prefer a vote thread that
includes potential workflows as well?


On Tue, Aug 5, 2014 at 5:40 PM, Karthik Kambatla <ka...@cloudera.com> wrote:

> Thanks for your opinions, everyone. Looks like most people are for the
> change and no one is against it. Let me start a vote for this.
>
>
> On Mon, Aug 4, 2014 at 4:44 PM, Tsuyoshi OZAWA <oz...@gmail.com>
> wrote:
>
>> Thank you for supplementation, Andrew. Yes, we should go step by step
>> and let's discuss review workflows on a another thread.
>>
>> Thanks,
>> - Tsuyoshi
>>
>> On Tue, Aug 5, 2014 at 8:23 AM, Andrew Wang <an...@cloudera.com>
>> wrote:
>> > I think we should take things one step at a time. Switching to git
>> > definitely opens up the possibility for better review workflows, but we
>> can
>> > discuss that on a different thread.
>> >
>> > A few different people have also mentioned Gerrit, so that'd be in the
>> > running along with Github (and I guess ReviewBoard).
>> >
>> > Thanks,
>> > Andrew
>> >
>> >
>> > On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA <
>> ozawa.tsuyoshi@gmail.com>
>> > wrote:
>> >
>> >> Thank you for great suggestion, Karthik. +1(non-binding) to use git.
>> >> I'm also using private git repository.
>> >> Additionally, I have one question. Will we accept github-based
>> >> development like Apache Spark? IHMO, it allow us to leverage Hadoop
>> >> development, because the cost of sending pull request is very low and
>> >> its review board is great. One concern is that the development
>> >> workflow can change and it can confuse us. What do you think?
>> >>
>> >> Thanks,
>> >> - Tsuyoshi
>> >>
>> >> On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla <ka...@cloudera.com>
>> >> wrote:
>> >> > Hi folks,
>> >> >
>> >> > From what I hear, a lot of devs use the git mirror for
>> >> development/reviews
>> >> > and use subversion primarily for checking code in. I was wondering
>> if it
>> >> > would make more sense just to move to git. In addition to subjective
>> >> liking
>> >> > of git, I see the following advantages in our workflow:
>> >> >
>> >> >    1. Feature branches - it becomes easier to work on them and keep
>> >> >    rebasing against the latest trunk.
>> >> >    2. Cherry-picks between branches automatically ensures the exact
>> same
>> >> >    commit message and tracks the lineage as well.
>> >> >    3. When cutting new branches and/or updating maven versions etc.,
>> it
>> >> >    allows doing all the work locally before pushing it to the main
>> >> branch.
>> >> >    4. Opens us up to potentially using other code-review tools.
>> (Gerrit?)
>> >> >    5. It is just more convenient.
>> >> >
>> >> > I am sure this was brought up before in different capacities. I
>> believe
>> >> the
>> >> > support for git in ASF is healthy now and several downstream projects
>> >> have
>> >> > moved. Again, from what I hear, ASF INFRA folks make the migration
>> >> process
>> >> > fairly easy.
>> >> >
>> >> > What do you all think?
>> >> >
>> >> > Thanks
>> >> > Karthik
>> >>
>> >>
>> >>
>> >> --
>> >> - Tsuyoshi
>> >>
>>
>>
>>
>> --
>> - Tsuyoshi
>>
>
>

Re: [DISCUSS] Migrate from svn to git for source control?

[Karthik Kambatla <ka...@cloudera.com>]

If we are to start a vote thread, will people prefer a vote thread that
includes potential workflows as well?


On Tue, Aug 5, 2014 at 5:40 PM, Karthik Kambatla <ka...@cloudera.com> wrote:

> Thanks for your opinions, everyone. Looks like most people are for the
> change and no one is against it. Let me start a vote for this.
>
>
> On Mon, Aug 4, 2014 at 4:44 PM, Tsuyoshi OZAWA <oz...@gmail.com>
> wrote:
>
>> Thank you for supplementation, Andrew. Yes, we should go step by step
>> and let's discuss review workflows on a another thread.
>>
>> Thanks,
>> - Tsuyoshi
>>
>> On Tue, Aug 5, 2014 at 8:23 AM, Andrew Wang <an...@cloudera.com>
>> wrote:
>> > I think we should take things one step at a time. Switching to git
>> > definitely opens up the possibility for better review workflows, but we
>> can
>> > discuss that on a different thread.
>> >
>> > A few different people have also mentioned Gerrit, so that'd be in the
>> > running along with Github (and I guess ReviewBoard).
>> >
>> > Thanks,
>> > Andrew
>> >
>> >
>> > On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA <
>> ozawa.tsuyoshi@gmail.com>
>> > wrote:
>> >
>> >> Thank you for great suggestion, Karthik. +1(non-binding) to use git.
>> >> I'm also using private git repository.
>> >> Additionally, I have one question. Will we accept github-based
>> >> development like Apache Spark? IHMO, it allow us to leverage Hadoop
>> >> development, because the cost of sending pull request is very low and
>> >> its review board is great. One concern is that the development
>> >> workflow can change and it can confuse us. What do you think?
>> >>
>> >> Thanks,
>> >> - Tsuyoshi
>> >>
>> >> On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla <ka...@cloudera.com>
>> >> wrote:
>> >> > Hi folks,
>> >> >
>> >> > From what I hear, a lot of devs use the git mirror for
>> >> development/reviews
>> >> > and use subversion primarily for checking code in. I was wondering
>> if it
>> >> > would make more sense just to move to git. In addition to subjective
>> >> liking
>> >> > of git, I see the following advantages in our workflow:
>> >> >
>> >> >    1. Feature branches - it becomes easier to work on them and keep
>> >> >    rebasing against the latest trunk.
>> >> >    2. Cherry-picks between branches automatically ensures the exact
>> same
>> >> >    commit message and tracks the lineage as well.
>> >> >    3. When cutting new branches and/or updating maven versions etc.,
>> it
>> >> >    allows doing all the work locally before pushing it to the main
>> >> branch.
>> >> >    4. Opens us up to potentially using other code-review tools.
>> (Gerrit?)
>> >> >    5. It is just more convenient.
>> >> >
>> >> > I am sure this was brought up before in different capacities. I
>> believe
>> >> the
>> >> > support for git in ASF is healthy now and several downstream projects
>> >> have
>> >> > moved. Again, from what I hear, ASF INFRA folks make the migration
>> >> process
>> >> > fairly easy.
>> >> >
>> >> > What do you all think?
>> >> >
>> >> > Thanks
>> >> > Karthik
>> >>
>> >>
>> >>
>> >> --
>> >> - Tsuyoshi
>> >>
>>
>>
>>
>> --
>> - Tsuyoshi
>>
>
>

Re: [DISCUSS] Migrate from svn to git for source control?

[Karthik Kambatla <ka...@cloudera.com>]

Thanks for your opinions, everyone. Looks like most people are for the
change and no one is against it. Let me start a vote for this.


On Mon, Aug 4, 2014 at 4:44 PM, Tsuyoshi OZAWA <oz...@gmail.com>
wrote:

> Thank you for supplementation, Andrew. Yes, we should go step by step
> and let's discuss review workflows on a another thread.
>
> Thanks,
> - Tsuyoshi
>
> On Tue, Aug 5, 2014 at 8:23 AM, Andrew Wang <an...@cloudera.com>
> wrote:
> > I think we should take things one step at a time. Switching to git
> > definitely opens up the possibility for better review workflows, but we
> can
> > discuss that on a different thread.
> >
> > A few different people have also mentioned Gerrit, so that'd be in the
> > running along with Github (and I guess ReviewBoard).
> >
> > Thanks,
> > Andrew
> >
> >
> > On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA <ozawa.tsuyoshi@gmail.com
> >
> > wrote:
> >
> >> Thank you for great suggestion, Karthik. +1(non-binding) to use git.
> >> I'm also using private git repository.
> >> Additionally, I have one question. Will we accept github-based
> >> development like Apache Spark? IHMO, it allow us to leverage Hadoop
> >> development, because the cost of sending pull request is very low and
> >> its review board is great. One concern is that the development
> >> workflow can change and it can confuse us. What do you think?
> >>
> >> Thanks,
> >> - Tsuyoshi
> >>
> >> On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla <ka...@cloudera.com>
> >> wrote:
> >> > Hi folks,
> >> >
> >> > From what I hear, a lot of devs use the git mirror for
> >> development/reviews
> >> > and use subversion primarily for checking code in. I was wondering if
> it
> >> > would make more sense just to move to git. In addition to subjective
> >> liking
> >> > of git, I see the following advantages in our workflow:
> >> >
> >> >    1. Feature branches - it becomes easier to work on them and keep
> >> >    rebasing against the latest trunk.
> >> >    2. Cherry-picks between branches automatically ensures the exact
> same
> >> >    commit message and tracks the lineage as well.
> >> >    3. When cutting new branches and/or updating maven versions etc.,
> it
> >> >    allows doing all the work locally before pushing it to the main
> >> branch.
> >> >    4. Opens us up to potentially using other code-review tools.
> (Gerrit?)
> >> >    5. It is just more convenient.
> >> >
> >> > I am sure this was brought up before in different capacities. I
> believe
> >> the
> >> > support for git in ASF is healthy now and several downstream projects
> >> have
> >> > moved. Again, from what I hear, ASF INFRA folks make the migration
> >> process
> >> > fairly easy.
> >> >
> >> > What do you all think?
> >> >
> >> > Thanks
> >> > Karthik
> >>
> >>
> >>
> >> --
> >> - Tsuyoshi
> >>
>
>
>
> --
> - Tsuyoshi
>

Re: [DISCUSS] Migrate from svn to git for source control?

[Karthik Kambatla <ka...@cloudera.com>]

Thanks for your opinions, everyone. Looks like most people are for the
change and no one is against it. Let me start a vote for this.


On Mon, Aug 4, 2014 at 4:44 PM, Tsuyoshi OZAWA <oz...@gmail.com>
wrote:

> Thank you for supplementation, Andrew. Yes, we should go step by step
> and let's discuss review workflows on a another thread.
>
> Thanks,
> - Tsuyoshi
>
> On Tue, Aug 5, 2014 at 8:23 AM, Andrew Wang <an...@cloudera.com>
> wrote:
> > I think we should take things one step at a time. Switching to git
> > definitely opens up the possibility for better review workflows, but we
> can
> > discuss that on a different thread.
> >
> > A few different people have also mentioned Gerrit, so that'd be in the
> > running along with Github (and I guess ReviewBoard).
> >
> > Thanks,
> > Andrew
> >
> >
> > On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA <ozawa.tsuyoshi@gmail.com
> >
> > wrote:
> >
> >> Thank you for great suggestion, Karthik. +1(non-binding) to use git.
> >> I'm also using private git repository.
> >> Additionally, I have one question. Will we accept github-based
> >> development like Apache Spark? IHMO, it allow us to leverage Hadoop
> >> development, because the cost of sending pull request is very low and
> >> its review board is great. One concern is that the development
> >> workflow can change and it can confuse us. What do you think?
> >>
> >> Thanks,
> >> - Tsuyoshi
> >>
> >> On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla <ka...@cloudera.com>
> >> wrote:
> >> > Hi folks,
> >> >
> >> > From what I hear, a lot of devs use the git mirror for
> >> development/reviews
> >> > and use subversion primarily for checking code in. I was wondering if
> it
> >> > would make more sense just to move to git. In addition to subjective
> >> liking
> >> > of git, I see the following advantages in our workflow:
> >> >
> >> >    1. Feature branches - it becomes easier to work on them and keep
> >> >    rebasing against the latest trunk.
> >> >    2. Cherry-picks between branches automatically ensures the exact
> same
> >> >    commit message and tracks the lineage as well.
> >> >    3. When cutting new branches and/or updating maven versions etc.,
> it
> >> >    allows doing all the work locally before pushing it to the main
> >> branch.
> >> >    4. Opens us up to potentially using other code-review tools.
> (Gerrit?)
> >> >    5. It is just more convenient.
> >> >
> >> > I am sure this was brought up before in different capacities. I
> believe
> >> the
> >> > support for git in ASF is healthy now and several downstream projects
> >> have
> >> > moved. Again, from what I hear, ASF INFRA folks make the migration
> >> process
> >> > fairly easy.
> >> >
> >> > What do you all think?
> >> >
> >> > Thanks
> >> > Karthik
> >>
> >>
> >>
> >> --
> >> - Tsuyoshi
> >>
>
>
>
> --
> - Tsuyoshi
>

Re: [DISCUSS] Migrate from svn to git for source control?

[Karthik Kambatla <ka...@cloudera.com>]

Thanks for your opinions, everyone. Looks like most people are for the
change and no one is against it. Let me start a vote for this.


On Mon, Aug 4, 2014 at 4:44 PM, Tsuyoshi OZAWA <oz...@gmail.com>
wrote:

> Thank you for supplementation, Andrew. Yes, we should go step by step
> and let's discuss review workflows on a another thread.
>
> Thanks,
> - Tsuyoshi
>
> On Tue, Aug 5, 2014 at 8:23 AM, Andrew Wang <an...@cloudera.com>
> wrote:
> > I think we should take things one step at a time. Switching to git
> > definitely opens up the possibility for better review workflows, but we
> can
> > discuss that on a different thread.
> >
> > A few different people have also mentioned Gerrit, so that'd be in the
> > running along with Github (and I guess ReviewBoard).
> >
> > Thanks,
> > Andrew
> >
> >
> > On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA <ozawa.tsuyoshi@gmail.com
> >
> > wrote:
> >
> >> Thank you for great suggestion, Karthik. +1(non-binding) to use git.
> >> I'm also using private git repository.
> >> Additionally, I have one question. Will we accept github-based
> >> development like Apache Spark? IHMO, it allow us to leverage Hadoop
> >> development, because the cost of sending pull request is very low and
> >> its review board is great. One concern is that the development
> >> workflow can change and it can confuse us. What do you think?
> >>
> >> Thanks,
> >> - Tsuyoshi
> >>
> >> On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla <ka...@cloudera.com>
> >> wrote:
> >> > Hi folks,
> >> >
> >> > From what I hear, a lot of devs use the git mirror for
> >> development/reviews
> >> > and use subversion primarily for checking code in. I was wondering if
> it
> >> > would make more sense just to move to git. In addition to subjective
> >> liking
> >> > of git, I see the following advantages in our workflow:
> >> >
> >> >    1. Feature branches - it becomes easier to work on them and keep
> >> >    rebasing against the latest trunk.
> >> >    2. Cherry-picks between branches automatically ensures the exact
> same
> >> >    commit message and tracks the lineage as well.
> >> >    3. When cutting new branches and/or updating maven versions etc.,
> it
> >> >    allows doing all the work locally before pushing it to the main
> >> branch.
> >> >    4. Opens us up to potentially using other code-review tools.
> (Gerrit?)
> >> >    5. It is just more convenient.
> >> >
> >> > I am sure this was brought up before in different capacities. I
> believe
> >> the
> >> > support for git in ASF is healthy now and several downstream projects
> >> have
> >> > moved. Again, from what I hear, ASF INFRA folks make the migration
> >> process
> >> > fairly easy.
> >> >
> >> > What do you all think?
> >> >
> >> > Thanks
> >> > Karthik
> >>
> >>
> >>
> >> --
> >> - Tsuyoshi
> >>
>
>
>
> --
> - Tsuyoshi
>

Re: [DISCUSS] Migrate from svn to git for source control?

[Karthik Kambatla <ka...@cloudera.com>]

Thanks for your opinions, everyone. Looks like most people are for the
change and no one is against it. Let me start a vote for this.


On Mon, Aug 4, 2014 at 4:44 PM, Tsuyoshi OZAWA <oz...@gmail.com>
wrote:

> Thank you for supplementation, Andrew. Yes, we should go step by step
> and let's discuss review workflows on a another thread.
>
> Thanks,
> - Tsuyoshi
>
> On Tue, Aug 5, 2014 at 8:23 AM, Andrew Wang <an...@cloudera.com>
> wrote:
> > I think we should take things one step at a time. Switching to git
> > definitely opens up the possibility for better review workflows, but we
> can
> > discuss that on a different thread.
> >
> > A few different people have also mentioned Gerrit, so that'd be in the
> > running along with Github (and I guess ReviewBoard).
> >
> > Thanks,
> > Andrew
> >
> >
> > On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA <ozawa.tsuyoshi@gmail.com
> >
> > wrote:
> >
> >> Thank you for great suggestion, Karthik. +1(non-binding) to use git.
> >> I'm also using private git repository.
> >> Additionally, I have one question. Will we accept github-based
> >> development like Apache Spark? IHMO, it allow us to leverage Hadoop
> >> development, because the cost of sending pull request is very low and
> >> its review board is great. One concern is that the development
> >> workflow can change and it can confuse us. What do you think?
> >>
> >> Thanks,
> >> - Tsuyoshi
> >>
> >> On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla <ka...@cloudera.com>
> >> wrote:
> >> > Hi folks,
> >> >
> >> > From what I hear, a lot of devs use the git mirror for
> >> development/reviews
> >> > and use subversion primarily for checking code in. I was wondering if
> it
> >> > would make more sense just to move to git. In addition to subjective
> >> liking
> >> > of git, I see the following advantages in our workflow:
> >> >
> >> >    1. Feature branches - it becomes easier to work on them and keep
> >> >    rebasing against the latest trunk.
> >> >    2. Cherry-picks between branches automatically ensures the exact
> same
> >> >    commit message and tracks the lineage as well.
> >> >    3. When cutting new branches and/or updating maven versions etc.,
> it
> >> >    allows doing all the work locally before pushing it to the main
> >> branch.
> >> >    4. Opens us up to potentially using other code-review tools.
> (Gerrit?)
> >> >    5. It is just more convenient.
> >> >
> >> > I am sure this was brought up before in different capacities. I
> believe
> >> the
> >> > support for git in ASF is healthy now and several downstream projects
> >> have
> >> > moved. Again, from what I hear, ASF INFRA folks make the migration
> >> process
> >> > fairly easy.
> >> >
> >> > What do you all think?
> >> >
> >> > Thanks
> >> > Karthik
> >>
> >>
> >>
> >> --
> >> - Tsuyoshi
> >>
>
>
>
> --
> - Tsuyoshi
>

Re: [DISCUSS] Migrate from svn to git for source control?

[Tsuyoshi OZAWA <oz...@gmail.com>]

Thank you for supplementation, Andrew. Yes, we should go step by step
and let's discuss review workflows on a another thread.

Thanks,
- Tsuyoshi

On Tue, Aug 5, 2014 at 8:23 AM, Andrew Wang <an...@cloudera.com> wrote:
> I think we should take things one step at a time. Switching to git
> definitely opens up the possibility for better review workflows, but we can
> discuss that on a different thread.
>
> A few different people have also mentioned Gerrit, so that'd be in the
> running along with Github (and I guess ReviewBoard).
>
> Thanks,
> Andrew
>
>
> On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA <oz...@gmail.com>
> wrote:
>
>> Thank you for great suggestion, Karthik. +1(non-binding) to use git.
>> I'm also using private git repository.
>> Additionally, I have one question. Will we accept github-based
>> development like Apache Spark? IHMO, it allow us to leverage Hadoop
>> development, because the cost of sending pull request is very low and
>> its review board is great. One concern is that the development
>> workflow can change and it can confuse us. What do you think?
>>
>> Thanks,
>> - Tsuyoshi
>>
>> On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla <ka...@cloudera.com>
>> wrote:
>> > Hi folks,
>> >
>> > From what I hear, a lot of devs use the git mirror for
>> development/reviews
>> > and use subversion primarily for checking code in. I was wondering if it
>> > would make more sense just to move to git. In addition to subjective
>> liking
>> > of git, I see the following advantages in our workflow:
>> >
>> >    1. Feature branches - it becomes easier to work on them and keep
>> >    rebasing against the latest trunk.
>> >    2. Cherry-picks between branches automatically ensures the exact same
>> >    commit message and tracks the lineage as well.
>> >    3. When cutting new branches and/or updating maven versions etc., it
>> >    allows doing all the work locally before pushing it to the main
>> branch.
>> >    4. Opens us up to potentially using other code-review tools. (Gerrit?)
>> >    5. It is just more convenient.
>> >
>> > I am sure this was brought up before in different capacities. I believe
>> the
>> > support for git in ASF is healthy now and several downstream projects
>> have
>> > moved. Again, from what I hear, ASF INFRA folks make the migration
>> process
>> > fairly easy.
>> >
>> > What do you all think?
>> >
>> > Thanks
>> > Karthik
>>
>>
>>
>> --
>> - Tsuyoshi
>>



-- 
- Tsuyoshi

Re: [DISCUSS] Migrate from svn to git for source control?

[Tsuyoshi OZAWA <oz...@gmail.com>]

Thank you for supplementation, Andrew. Yes, we should go step by step
and let's discuss review workflows on a another thread.

Thanks,
- Tsuyoshi

On Tue, Aug 5, 2014 at 8:23 AM, Andrew Wang <an...@cloudera.com> wrote:
> I think we should take things one step at a time. Switching to git
> definitely opens up the possibility for better review workflows, but we can
> discuss that on a different thread.
>
> A few different people have also mentioned Gerrit, so that'd be in the
> running along with Github (and I guess ReviewBoard).
>
> Thanks,
> Andrew
>
>
> On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA <oz...@gmail.com>
> wrote:
>
>> Thank you for great suggestion, Karthik. +1(non-binding) to use git.
>> I'm also using private git repository.
>> Additionally, I have one question. Will we accept github-based
>> development like Apache Spark? IHMO, it allow us to leverage Hadoop
>> development, because the cost of sending pull request is very low and
>> its review board is great. One concern is that the development
>> workflow can change and it can confuse us. What do you think?
>>
>> Thanks,
>> - Tsuyoshi
>>
>> On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla <ka...@cloudera.com>
>> wrote:
>> > Hi folks,
>> >
>> > From what I hear, a lot of devs use the git mirror for
>> development/reviews
>> > and use subversion primarily for checking code in. I was wondering if it
>> > would make more sense just to move to git. In addition to subjective
>> liking
>> > of git, I see the following advantages in our workflow:
>> >
>> >    1. Feature branches - it becomes easier to work on them and keep
>> >    rebasing against the latest trunk.
>> >    2. Cherry-picks between branches automatically ensures the exact same
>> >    commit message and tracks the lineage as well.
>> >    3. When cutting new branches and/or updating maven versions etc., it
>> >    allows doing all the work locally before pushing it to the main
>> branch.
>> >    4. Opens us up to potentially using other code-review tools. (Gerrit?)
>> >    5. It is just more convenient.
>> >
>> > I am sure this was brought up before in different capacities. I believe
>> the
>> > support for git in ASF is healthy now and several downstream projects
>> have
>> > moved. Again, from what I hear, ASF INFRA folks make the migration
>> process
>> > fairly easy.
>> >
>> > What do you all think?
>> >
>> > Thanks
>> > Karthik
>>
>>
>>
>> --
>> - Tsuyoshi
>>



-- 
- Tsuyoshi

Re: [DISCUSS] Migrate from svn to git for source control?

[Tsuyoshi OZAWA <oz...@gmail.com>]

Thank you for supplementation, Andrew. Yes, we should go step by step
and let's discuss review workflows on a another thread.

Thanks,
- Tsuyoshi

On Tue, Aug 5, 2014 at 8:23 AM, Andrew Wang <an...@cloudera.com> wrote:
> I think we should take things one step at a time. Switching to git
> definitely opens up the possibility for better review workflows, but we can
> discuss that on a different thread.
>
> A few different people have also mentioned Gerrit, so that'd be in the
> running along with Github (and I guess ReviewBoard).
>
> Thanks,
> Andrew
>
>
> On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA <oz...@gmail.com>
> wrote:
>
>> Thank you for great suggestion, Karthik. +1(non-binding) to use git.
>> I'm also using private git repository.
>> Additionally, I have one question. Will we accept github-based
>> development like Apache Spark? IHMO, it allow us to leverage Hadoop
>> development, because the cost of sending pull request is very low and
>> its review board is great. One concern is that the development
>> workflow can change and it can confuse us. What do you think?
>>
>> Thanks,
>> - Tsuyoshi
>>
>> On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla <ka...@cloudera.com>
>> wrote:
>> > Hi folks,
>> >
>> > From what I hear, a lot of devs use the git mirror for
>> development/reviews
>> > and use subversion primarily for checking code in. I was wondering if it
>> > would make more sense just to move to git. In addition to subjective
>> liking
>> > of git, I see the following advantages in our workflow:
>> >
>> >    1. Feature branches - it becomes easier to work on them and keep
>> >    rebasing against the latest trunk.
>> >    2. Cherry-picks between branches automatically ensures the exact same
>> >    commit message and tracks the lineage as well.
>> >    3. When cutting new branches and/or updating maven versions etc., it
>> >    allows doing all the work locally before pushing it to the main
>> branch.
>> >    4. Opens us up to potentially using other code-review tools. (Gerrit?)
>> >    5. It is just more convenient.
>> >
>> > I am sure this was brought up before in different capacities. I believe
>> the
>> > support for git in ASF is healthy now and several downstream projects
>> have
>> > moved. Again, from what I hear, ASF INFRA folks make the migration
>> process
>> > fairly easy.
>> >
>> > What do you all think?
>> >
>> > Thanks
>> > Karthik
>>
>>
>>
>> --
>> - Tsuyoshi
>>



-- 
- Tsuyoshi

Re: [DISCUSS] Migrate from svn to git for source control?

[Tsuyoshi OZAWA <oz...@gmail.com>]

Thank you for supplementation, Andrew. Yes, we should go step by step
and let's discuss review workflows on a another thread.

Thanks,
- Tsuyoshi

On Tue, Aug 5, 2014 at 8:23 AM, Andrew Wang <an...@cloudera.com> wrote:
> I think we should take things one step at a time. Switching to git
> definitely opens up the possibility for better review workflows, but we can
> discuss that on a different thread.
>
> A few different people have also mentioned Gerrit, so that'd be in the
> running along with Github (and I guess ReviewBoard).
>
> Thanks,
> Andrew
>
>
> On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA <oz...@gmail.com>
> wrote:
>
>> Thank you for great suggestion, Karthik. +1(non-binding) to use git.
>> I'm also using private git repository.
>> Additionally, I have one question. Will we accept github-based
>> development like Apache Spark? IHMO, it allow us to leverage Hadoop
>> development, because the cost of sending pull request is very low and
>> its review board is great. One concern is that the development
>> workflow can change and it can confuse us. What do you think?
>>
>> Thanks,
>> - Tsuyoshi
>>
>> On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla <ka...@cloudera.com>
>> wrote:
>> > Hi folks,
>> >
>> > From what I hear, a lot of devs use the git mirror for
>> development/reviews
>> > and use subversion primarily for checking code in. I was wondering if it
>> > would make more sense just to move to git. In addition to subjective
>> liking
>> > of git, I see the following advantages in our workflow:
>> >
>> >    1. Feature branches - it becomes easier to work on them and keep
>> >    rebasing against the latest trunk.
>> >    2. Cherry-picks between branches automatically ensures the exact same
>> >    commit message and tracks the lineage as well.
>> >    3. When cutting new branches and/or updating maven versions etc., it
>> >    allows doing all the work locally before pushing it to the main
>> branch.
>> >    4. Opens us up to potentially using other code-review tools. (Gerrit?)
>> >    5. It is just more convenient.
>> >
>> > I am sure this was brought up before in different capacities. I believe
>> the
>> > support for git in ASF is healthy now and several downstream projects
>> have
>> > moved. Again, from what I hear, ASF INFRA folks make the migration
>> process
>> > fairly easy.
>> >
>> > What do you all think?
>> >
>> > Thanks
>> > Karthik
>>
>>
>>
>> --
>> - Tsuyoshi
>>



-- 
- Tsuyoshi

Re: [DISCUSS] Migrate from svn to git for source control?

[Andrew Wang <an...@cloudera.com>]

I think we should take things one step at a time. Switching to git
definitely opens up the possibility for better review workflows, but we can
discuss that on a different thread.

A few different people have also mentioned Gerrit, so that'd be in the
running along with Github (and I guess ReviewBoard).

Thanks,
Andrew


On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA <oz...@gmail.com>
wrote:

> Thank you for great suggestion, Karthik. +1(non-binding) to use git.
> I'm also using private git repository.
> Additionally, I have one question. Will we accept github-based
> development like Apache Spark? IHMO, it allow us to leverage Hadoop
> development, because the cost of sending pull request is very low and
> its review board is great. One concern is that the development
> workflow can change and it can confuse us. What do you think?
>
> Thanks,
> - Tsuyoshi
>
> On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla <ka...@cloudera.com>
> wrote:
> > Hi folks,
> >
> > From what I hear, a lot of devs use the git mirror for
> development/reviews
> > and use subversion primarily for checking code in. I was wondering if it
> > would make more sense just to move to git. In addition to subjective
> liking
> > of git, I see the following advantages in our workflow:
> >
> >    1. Feature branches - it becomes easier to work on them and keep
> >    rebasing against the latest trunk.
> >    2. Cherry-picks between branches automatically ensures the exact same
> >    commit message and tracks the lineage as well.
> >    3. When cutting new branches and/or updating maven versions etc., it
> >    allows doing all the work locally before pushing it to the main
> branch.
> >    4. Opens us up to potentially using other code-review tools. (Gerrit?)
> >    5. It is just more convenient.
> >
> > I am sure this was brought up before in different capacities. I believe
> the
> > support for git in ASF is healthy now and several downstream projects
> have
> > moved. Again, from what I hear, ASF INFRA folks make the migration
> process
> > fairly easy.
> >
> > What do you all think?
> >
> > Thanks
> > Karthik
>
>
>
> --
> - Tsuyoshi
>

Re: [DISCUSS] Migrate from svn to git for source control?

[Andrew Wang <an...@cloudera.com>]

I think we should take things one step at a time. Switching to git
definitely opens up the possibility for better review workflows, but we can
discuss that on a different thread.

A few different people have also mentioned Gerrit, so that'd be in the
running along with Github (and I guess ReviewBoard).

Thanks,
Andrew


On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA <oz...@gmail.com>
wrote:

> Thank you for great suggestion, Karthik. +1(non-binding) to use git.
> I'm also using private git repository.
> Additionally, I have one question. Will we accept github-based
> development like Apache Spark? IHMO, it allow us to leverage Hadoop
> development, because the cost of sending pull request is very low and
> its review board is great. One concern is that the development
> workflow can change and it can confuse us. What do you think?
>
> Thanks,
> - Tsuyoshi
>
> On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla <ka...@cloudera.com>
> wrote:
> > Hi folks,
> >
> > From what I hear, a lot of devs use the git mirror for
> development/reviews
> > and use subversion primarily for checking code in. I was wondering if it
> > would make more sense just to move to git. In addition to subjective
> liking
> > of git, I see the following advantages in our workflow:
> >
> >    1. Feature branches - it becomes easier to work on them and keep
> >    rebasing against the latest trunk.
> >    2. Cherry-picks between branches automatically ensures the exact same
> >    commit message and tracks the lineage as well.
> >    3. When cutting new branches and/or updating maven versions etc., it
> >    allows doing all the work locally before pushing it to the main
> branch.
> >    4. Opens us up to potentially using other code-review tools. (Gerrit?)
> >    5. It is just more convenient.
> >
> > I am sure this was brought up before in different capacities. I believe
> the
> > support for git in ASF is healthy now and several downstream projects
> have
> > moved. Again, from what I hear, ASF INFRA folks make the migration
> process
> > fairly easy.
> >
> > What do you all think?
> >
> > Thanks
> > Karthik
>
>
>
> --
> - Tsuyoshi
>

Re: [DISCUSS] Migrate from svn to git for source control?

[Andrew Wang <an...@cloudera.com>]

I think we should take things one step at a time. Switching to git
definitely opens up the possibility for better review workflows, but we can
discuss that on a different thread.

A few different people have also mentioned Gerrit, so that'd be in the
running along with Github (and I guess ReviewBoard).

Thanks,
Andrew


On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA <oz...@gmail.com>
wrote:

> Thank you for great suggestion, Karthik. +1(non-binding) to use git.
> I'm also using private git repository.
> Additionally, I have one question. Will we accept github-based
> development like Apache Spark? IHMO, it allow us to leverage Hadoop
> development, because the cost of sending pull request is very low and
> its review board is great. One concern is that the development
> workflow can change and it can confuse us. What do you think?
>
> Thanks,
> - Tsuyoshi
>
> On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla <ka...@cloudera.com>
> wrote:
> > Hi folks,
> >
> > From what I hear, a lot of devs use the git mirror for
> development/reviews
> > and use subversion primarily for checking code in. I was wondering if it
> > would make more sense just to move to git. In addition to subjective
> liking
> > of git, I see the following advantages in our workflow:
> >
> >    1. Feature branches - it becomes easier to work on them and keep
> >    rebasing against the latest trunk.
> >    2. Cherry-picks between branches automatically ensures the exact same
> >    commit message and tracks the lineage as well.
> >    3. When cutting new branches and/or updating maven versions etc., it
> >    allows doing all the work locally before pushing it to the main
> branch.
> >    4. Opens us up to potentially using other code-review tools. (Gerrit?)
> >    5. It is just more convenient.
> >
> > I am sure this was brought up before in different capacities. I believe
> the
> > support for git in ASF is healthy now and several downstream projects
> have
> > moved. Again, from what I hear, ASF INFRA folks make the migration
> process
> > fairly easy.
> >
> > What do you all think?
> >
> > Thanks
> > Karthik
>
>
>
> --
> - Tsuyoshi
>

Re: [DISCUSS] Migrate from svn to git for source control?

[Andrew Wang <an...@cloudera.com>]

I think we should take things one step at a time. Switching to git
definitely opens up the possibility for better review workflows, but we can
discuss that on a different thread.

A few different people have also mentioned Gerrit, so that'd be in the
running along with Github (and I guess ReviewBoard).

Thanks,
Andrew


On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA <oz...@gmail.com>
wrote:

> Thank you for great suggestion, Karthik. +1(non-binding) to use git.
> I'm also using private git repository.
> Additionally, I have one question. Will we accept github-based
> development like Apache Spark? IHMO, it allow us to leverage Hadoop
> development, because the cost of sending pull request is very low and
> its review board is great. One concern is that the development
> workflow can change and it can confuse us. What do you think?
>
> Thanks,
> - Tsuyoshi
>
> On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla <ka...@cloudera.com>
> wrote:
> > Hi folks,
> >
> > From what I hear, a lot of devs use the git mirror for
> development/reviews
> > and use subversion primarily for checking code in. I was wondering if it
> > would make more sense just to move to git. In addition to subjective
> liking
> > of git, I see the following advantages in our workflow:
> >
> >    1. Feature branches - it becomes easier to work on them and keep
> >    rebasing against the latest trunk.
> >    2. Cherry-picks between branches automatically ensures the exact same
> >    commit message and tracks the lineage as well.
> >    3. When cutting new branches and/or updating maven versions etc., it
> >    allows doing all the work locally before pushing it to the main
> branch.
> >    4. Opens us up to potentially using other code-review tools. (Gerrit?)
> >    5. It is just more convenient.
> >
> > I am sure this was brought up before in different capacities. I believe
> the
> > support for git in ASF is healthy now and several downstream projects
> have
> > moved. Again, from what I hear, ASF INFRA folks make the migration
> process
> > fairly easy.
> >
> > What do you all think?
> >
> > Thanks
> > Karthik
>
>
>
> --
> - Tsuyoshi
>

Re: [DISCUSS] Migrate from svn to git for source control?

[Tsuyoshi OZAWA <oz...@gmail.com>]

Thank you for great suggestion, Karthik. +1(non-binding) to use git.
I'm also using private git repository.
Additionally, I have one question. Will we accept github-based
development like Apache Spark? IHMO, it allow us to leverage Hadoop
development, because the cost of sending pull request is very low and
its review board is great. One concern is that the development
workflow can change and it can confuse us. What do you think?

Thanks,
- Tsuyoshi

On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla <ka...@cloudera.com> wrote:
> Hi folks,
>
> From what I hear, a lot of devs use the git mirror for development/reviews
> and use subversion primarily for checking code in. I was wondering if it
> would make more sense just to move to git. In addition to subjective liking
> of git, I see the following advantages in our workflow:
>
>    1. Feature branches - it becomes easier to work on them and keep
>    rebasing against the latest trunk.
>    2. Cherry-picks between branches automatically ensures the exact same
>    commit message and tracks the lineage as well.
>    3. When cutting new branches and/or updating maven versions etc., it
>    allows doing all the work locally before pushing it to the main branch.
>    4. Opens us up to potentially using other code-review tools. (Gerrit?)
>    5. It is just more convenient.
>
> I am sure this was brought up before in different capacities. I believe the
> support for git in ASF is healthy now and several downstream projects have
> moved. Again, from what I hear, ASF INFRA folks make the migration process
> fairly easy.
>
> What do you all think?
>
> Thanks
> Karthik



-- 
- Tsuyoshi

Re: [DISCUSS] Migrate from svn to git for source control?

[Alejandro Abdelnur <tu...@gmail.com>]

+1, we did it for Oozie a while back and was painless with minor issues in
Jenkins jobs

Rebasing feature branches on latest trunk may be tricky as that may require
a force push and if I'm not mistaken force pushes are disabled in Apache
GIT.

thx


On Fri, Aug 1, 2014 at 4:43 PM, Karthik Kambatla <ka...@cloudera.com> wrote:

> Hi folks,
>
> From what I hear, a lot of devs use the git mirror for development/reviews
> and use subversion primarily for checking code in. I was wondering if it
> would make more sense just to move to git. In addition to subjective liking
> of git, I see the following advantages in our workflow:
>
>    1. Feature branches - it becomes easier to work on them and keep
>    rebasing against the latest trunk.
>    2. Cherry-picks between branches automatically ensures the exact same
>    commit message and tracks the lineage as well.
>    3. When cutting new branches and/or updating maven versions etc., it
>    allows doing all the work locally before pushing it to the main branch.
>    4. Opens us up to potentially using other code-review tools. (Gerrit?)
>    5. It is just more convenient.
>
> I am sure this was brought up before in different capacities. I believe the
> support for git in ASF is healthy now and several downstream projects have
> moved. Again, from what I hear, ASF INFRA folks make the migration process
> fairly easy.
>
> What do you all think?
>
> Thanks
> Karthik
>

Re: [DISCUSS] Migrate from svn to git for source control?

[Alejandro Abdelnur <tu...@gmail.com>]

+1, we did it for Oozie a while back and was painless with minor issues in
Jenkins jobs

Rebasing feature branches on latest trunk may be tricky as that may require
a force push and if I'm not mistaken force pushes are disabled in Apache
GIT.

thx


On Fri, Aug 1, 2014 at 4:43 PM, Karthik Kambatla <ka...@cloudera.com> wrote:

> Hi folks,
>
> From what I hear, a lot of devs use the git mirror for development/reviews
> and use subversion primarily for checking code in. I was wondering if it
> would make more sense just to move to git. In addition to subjective liking
> of git, I see the following advantages in our workflow:
>
>    1. Feature branches - it becomes easier to work on them and keep
>    rebasing against the latest trunk.
>    2. Cherry-picks between branches automatically ensures the exact same
>    commit message and tracks the lineage as well.
>    3. When cutting new branches and/or updating maven versions etc., it
>    allows doing all the work locally before pushing it to the main branch.
>    4. Opens us up to potentially using other code-review tools. (Gerrit?)
>    5. It is just more convenient.
>
> I am sure this was brought up before in different capacities. I believe the
> support for git in ASF is healthy now and several downstream projects have
> moved. Again, from what I hear, ASF INFRA folks make the migration process
> fairly easy.
>
> What do you all think?
>
> Thanks
> Karthik
>

RE: [DISCUSS] Migrate from svn to git for source control?

[Vikas Parashar <vi...@fosteringlinux.com>]

+1.. Now git is more handy. We can easily switch between the branches. As
we all know, LINUX kernel is on same and well managed.

We can all have own local repo and can commit to stream once we will
connected to web.
On 3 Aug 2014 12:09, "Liu, Yi A" <yi...@intel.com> wrote:

> +1, Git is more convenient for development and we can switch easily
> between branches and can have local branches.
>
> Regards,
> Yi Liu
>
>
> -----Original Message-----
> From: Karthik Kambatla [mailto:kasha@cloudera.com]
> Sent: Saturday, August 02, 2014 7:44 AM
> To: common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org;
> mapreduce-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org
> Subject: [DISCUSS] Migrate from svn to git for source control?
>
> Hi folks,
>
> From what I hear, a lot of devs use the git mirror for development/reviews
> and use subversion primarily for checking code in. I was wondering if it
> would make more sense just to move to git. In addition to subjective liking
> of git, I see the following advantages in our workflow:
>
>    1. Feature branches - it becomes easier to work on them and keep
>    rebasing against the latest trunk.
>    2. Cherry-picks between branches automatically ensures the exact same
>    commit message and tracks the lineage as well.
>    3. When cutting new branches and/or updating maven versions etc., it
>    allows doing all the work locally before pushing it to the main branch.
>    4. Opens us up to potentially using other code-review tools. (Gerrit?)
>    5. It is just more convenient.
>
> I am sure this was brought up before in different capacities. I believe
> the support for git in ASF is healthy now and several downstream projects
> have moved. Again, from what I hear, ASF INFRA folks make the migration
> process fairly easy.
>
> What do you all think?
>
> Thanks
> Karthik
>

RE: [DISCUSS] Migrate from svn to git for source control?

["Liu, Yi A" <yi...@intel.com>]

+1, Git is more convenient for development and we can switch easily between branches and can have local branches.

Regards,
Yi Liu


-----Original Message-----
From: Karthik Kambatla [mailto:kasha@cloudera.com] 
Sent: Saturday, August 02, 2014 7:44 AM
To: common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org
Subject: [DISCUSS] Migrate from svn to git for source control?

Hi folks,

From what I hear, a lot of devs use the git mirror for development/reviews and use subversion primarily for checking code in. I was wondering if it would make more sense just to move to git. In addition to subjective liking of git, I see the following advantages in our workflow:

   1. Feature branches - it becomes easier to work on them and keep
   rebasing against the latest trunk.
   2. Cherry-picks between branches automatically ensures the exact same
   commit message and tracks the lineage as well.
   3. When cutting new branches and/or updating maven versions etc., it
   allows doing all the work locally before pushing it to the main branch.
   4. Opens us up to potentially using other code-review tools. (Gerrit?)
   5. It is just more convenient.

I am sure this was brought up before in different capacities. I believe the support for git in ASF is healthy now and several downstream projects have moved. Again, from what I hear, ASF INFRA folks make the migration process fairly easy.

What do you all think?

Thanks
Karthik

RE: [DISCUSS] Migrate from svn to git for source control?

["Liu, Yi A" <yi...@intel.com>]

+1, Git is more convenient for development and we can switch easily between branches and can have local branches.

Regards,
Yi Liu


-----Original Message-----
From: Karthik Kambatla [mailto:kasha@cloudera.com] 
Sent: Saturday, August 02, 2014 7:44 AM
To: common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org
Subject: [DISCUSS] Migrate from svn to git for source control?

Hi folks,

From what I hear, a lot of devs use the git mirror for development/reviews and use subversion primarily for checking code in. I was wondering if it would make more sense just to move to git. In addition to subjective liking of git, I see the following advantages in our workflow:

   1. Feature branches - it becomes easier to work on them and keep
   rebasing against the latest trunk.
   2. Cherry-picks between branches automatically ensures the exact same
   commit message and tracks the lineage as well.
   3. When cutting new branches and/or updating maven versions etc., it
   allows doing all the work locally before pushing it to the main branch.
   4. Opens us up to potentially using other code-review tools. (Gerrit?)
   5. It is just more convenient.

I am sure this was brought up before in different capacities. I believe the support for git in ASF is healthy now and several downstream projects have moved. Again, from what I hear, ASF INFRA folks make the migration process fairly easy.

What do you all think?

Thanks
Karthik

Re: [DISCUSS] Migrate from svn to git for source control?

[Tsuyoshi OZAWA <oz...@gmail.com>]

Thank you for great suggestion, Karthik. +1(non-binding) to use git.
I'm also using private git repository.
Additionally, I have one question. Will we accept github-based
development like Apache Spark? IHMO, it allow us to leverage Hadoop
development, because the cost of sending pull request is very low and
its review board is great. One concern is that the development
workflow can change and it can confuse us. What do you think?

Thanks,
- Tsuyoshi

On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla <ka...@cloudera.com> wrote:
> Hi folks,
>
> From what I hear, a lot of devs use the git mirror for development/reviews
> and use subversion primarily for checking code in. I was wondering if it
> would make more sense just to move to git. In addition to subjective liking
> of git, I see the following advantages in our workflow:
>
>    1. Feature branches - it becomes easier to work on them and keep
>    rebasing against the latest trunk.
>    2. Cherry-picks between branches automatically ensures the exact same
>    commit message and tracks the lineage as well.
>    3. When cutting new branches and/or updating maven versions etc., it
>    allows doing all the work locally before pushing it to the main branch.
>    4. Opens us up to potentially using other code-review tools. (Gerrit?)
>    5. It is just more convenient.
>
> I am sure this was brought up before in different capacities. I believe the
> support for git in ASF is healthy now and several downstream projects have
> moved. Again, from what I hear, ASF INFRA folks make the migration process
> fairly easy.
>
> What do you all think?
>
> Thanks
> Karthik



-- 
- Tsuyoshi

Re: [DISCUSS] Migrate from svn to git for source control?

[Andrew Wang <an...@cloudera.com>]

Thanks for starting this thread Karthik! Big +1 from me. I only use svn
when I have to commit things or work on the site, otherwise it's always the
git mirror or local git repos.

Considering that the git mirror works as well as it does, I'd expect this
to be a pretty smooth transition.

Best,
Andrew


On Fri, Aug 1, 2014 at 4:43 PM, Karthik Kambatla <ka...@cloudera.com> wrote:

> Hi folks,
>
> From what I hear, a lot of devs use the git mirror for development/reviews
> and use subversion primarily for checking code in. I was wondering if it
> would make more sense just to move to git. In addition to subjective liking
> of git, I see the following advantages in our workflow:
>
>    1. Feature branches - it becomes easier to work on them and keep
>    rebasing against the latest trunk.
>    2. Cherry-picks between branches automatically ensures the exact same
>    commit message and tracks the lineage as well.
>    3. When cutting new branches and/or updating maven versions etc., it
>    allows doing all the work locally before pushing it to the main branch.
>    4. Opens us up to potentially using other code-review tools. (Gerrit?)
>    5. It is just more convenient.
>
> I am sure this was brought up before in different capacities. I believe the
> support for git in ASF is healthy now and several downstream projects have
> moved. Again, from what I hear, ASF INFRA folks make the migration process
> fairly easy.
>
> What do you all think?
>
> Thanks
> Karthik
>

Re: [DISCUSS] Migrate from svn to git for source control?

[Andrew Wang <an...@cloudera.com>]

Thanks for starting this thread Karthik! Big +1 from me. I only use svn
when I have to commit things or work on the site, otherwise it's always the
git mirror or local git repos.

Considering that the git mirror works as well as it does, I'd expect this
to be a pretty smooth transition.

Best,
Andrew


On Fri, Aug 1, 2014 at 4:43 PM, Karthik Kambatla <ka...@cloudera.com> wrote:

> Hi folks,
>
> From what I hear, a lot of devs use the git mirror for development/reviews
> and use subversion primarily for checking code in. I was wondering if it
> would make more sense just to move to git. In addition to subjective liking
> of git, I see the following advantages in our workflow:
>
>    1. Feature branches - it becomes easier to work on them and keep
>    rebasing against the latest trunk.
>    2. Cherry-picks between branches automatically ensures the exact same
>    commit message and tracks the lineage as well.
>    3. When cutting new branches and/or updating maven versions etc., it
>    allows doing all the work locally before pushing it to the main branch.
>    4. Opens us up to potentially using other code-review tools. (Gerrit?)
>    5. It is just more convenient.
>
> I am sure this was brought up before in different capacities. I believe the
> support for git in ASF is healthy now and several downstream projects have
> moved. Again, from what I hear, ASF INFRA folks make the migration process
> fairly easy.
>
> What do you all think?
>
> Thanks
> Karthik
>

Re: [DISCUSS] Migrate from svn to git for source control?

[Henry Saputra <he...@gmail.com>]

+1 for this =)

Been using Github mirror for development anyway =)

We at Apache Gora moved to Git recently and it had been pretty smooth
transition.

- Henry

On Fri, Aug 1, 2014 at 4:43 PM, Karthik Kambatla <ka...@cloudera.com> wrote:
> Hi folks,
>
> From what I hear, a lot of devs use the git mirror for development/reviews
> and use subversion primarily for checking code in. I was wondering if it
> would make more sense just to move to git. In addition to subjective liking
> of git, I see the following advantages in our workflow:
>
>    1. Feature branches - it becomes easier to work on them and keep
>    rebasing against the latest trunk.
>    2. Cherry-picks between branches automatically ensures the exact same
>    commit message and tracks the lineage as well.
>    3. When cutting new branches and/or updating maven versions etc., it
>    allows doing all the work locally before pushing it to the main branch.
>    4. Opens us up to potentially using other code-review tools. (Gerrit?)
>    5. It is just more convenient.
>
> I am sure this was brought up before in different capacities. I believe the
> support for git in ASF is healthy now and several downstream projects have
> moved. Again, from what I hear, ASF INFRA folks make the migration process
> fairly easy.
>
> What do you all think?
>
> Thanks
> Karthik

RE: [DISCUSS] Migrate from svn to git for source control?

["Liu, Yi A" <yi...@intel.com>]

+1, Git is more convenient for development and we can switch easily between branches and can have local branches.

Regards,
Yi Liu


-----Original Message-----
From: Karthik Kambatla [mailto:kasha@cloudera.com] 
Sent: Saturday, August 02, 2014 7:44 AM
To: common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org
Subject: [DISCUSS] Migrate from svn to git for source control?

Hi folks,

From what I hear, a lot of devs use the git mirror for development/reviews and use subversion primarily for checking code in. I was wondering if it would make more sense just to move to git. In addition to subjective liking of git, I see the following advantages in our workflow:

   1. Feature branches - it becomes easier to work on them and keep
   rebasing against the latest trunk.
   2. Cherry-picks between branches automatically ensures the exact same
   commit message and tracks the lineage as well.
   3. When cutting new branches and/or updating maven versions etc., it
   allows doing all the work locally before pushing it to the main branch.
   4. Opens us up to potentially using other code-review tools. (Gerrit?)
   5. It is just more convenient.

I am sure this was brought up before in different capacities. I believe the support for git in ASF is healthy now and several downstream projects have moved. Again, from what I hear, ASF INFRA folks make the migration process fairly easy.

What do you all think?

Thanks
Karthik

Re: [DISCUSS] Migrate from svn to git for source control?

[Henry Saputra <he...@gmail.com>]

+1 for this =)

Been using Github mirror for development anyway =)

We at Apache Gora moved to Git recently and it had been pretty smooth
transition.

- Henry

On Fri, Aug 1, 2014 at 4:43 PM, Karthik Kambatla <ka...@cloudera.com> wrote:
> Hi folks,
>
> From what I hear, a lot of devs use the git mirror for development/reviews
> and use subversion primarily for checking code in. I was wondering if it
> would make more sense just to move to git. In addition to subjective liking
> of git, I see the following advantages in our workflow:
>
>    1. Feature branches - it becomes easier to work on them and keep
>    rebasing against the latest trunk.
>    2. Cherry-picks between branches automatically ensures the exact same
>    commit message and tracks the lineage as well.
>    3. When cutting new branches and/or updating maven versions etc., it
>    allows doing all the work locally before pushing it to the main branch.
>    4. Opens us up to potentially using other code-review tools. (Gerrit?)
>    5. It is just more convenient.
>
> I am sure this was brought up before in different capacities. I believe the
> support for git in ASF is healthy now and several downstream projects have
> moved. Again, from what I hear, ASF INFRA folks make the migration process
> fairly easy.
>
> What do you all think?
>
> Thanks
> Karthik

Re: [DISCUSS] Migrate from svn to git for source control?

[Henry Saputra <he...@gmail.com>]

+1 for this =)

Been using Github mirror for development anyway =)

We at Apache Gora moved to Git recently and it had been pretty smooth
transition.

- Henry

On Fri, Aug 1, 2014 at 4:43 PM, Karthik Kambatla <ka...@cloudera.com> wrote:
> Hi folks,
>
> From what I hear, a lot of devs use the git mirror for development/reviews
> and use subversion primarily for checking code in. I was wondering if it
> would make more sense just to move to git. In addition to subjective liking
> of git, I see the following advantages in our workflow:
>
>    1. Feature branches - it becomes easier to work on them and keep
>    rebasing against the latest trunk.
>    2. Cherry-picks between branches automatically ensures the exact same
>    commit message and tracks the lineage as well.
>    3. When cutting new branches and/or updating maven versions etc., it
>    allows doing all the work locally before pushing it to the main branch.
>    4. Opens us up to potentially using other code-review tools. (Gerrit?)
>    5. It is just more convenient.
>
> I am sure this was brought up before in different capacities. I believe the
> support for git in ASF is healthy now and several downstream projects have
> moved. Again, from what I hear, ASF INFRA folks make the migration process
> fairly easy.
>
> What do you all think?
>
> Thanks
> Karthik

Re: [DISCUSS] Migrate from svn to git for source control?

[Tsuyoshi OZAWA <oz...@gmail.com>]

Thank you for great suggestion, Karthik. +1(non-binding) to use git.
I'm also using private git repository.
Additionally, I have one question. Will we accept github-based
development like Apache Spark? IHMO, it allow us to leverage Hadoop
development, because the cost of sending pull request is very low and
its review board is great. One concern is that the development
workflow can change and it can confuse us. What do you think?

Thanks,
- Tsuyoshi

On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla <ka...@cloudera.com> wrote:
> Hi folks,
>
> From what I hear, a lot of devs use the git mirror for development/reviews
> and use subversion primarily for checking code in. I was wondering if it
> would make more sense just to move to git. In addition to subjective liking
> of git, I see the following advantages in our workflow:
>
>    1. Feature branches - it becomes easier to work on them and keep
>    rebasing against the latest trunk.
>    2. Cherry-picks between branches automatically ensures the exact same
>    commit message and tracks the lineage as well.
>    3. When cutting new branches and/or updating maven versions etc., it
>    allows doing all the work locally before pushing it to the main branch.
>    4. Opens us up to potentially using other code-review tools. (Gerrit?)
>    5. It is just more convenient.
>
> I am sure this was brought up before in different capacities. I believe the
> support for git in ASF is healthy now and several downstream projects have
> moved. Again, from what I hear, ASF INFRA folks make the migration process
> fairly easy.
>
> What do you all think?
>
> Thanks
> Karthik



-- 
- Tsuyoshi

Re: [DISCUSS] Migrate from svn to git for source control?

[Alejandro Abdelnur <tu...@gmail.com>]

+1, we did it for Oozie a while back and was painless with minor issues in
Jenkins jobs

Rebasing feature branches on latest trunk may be tricky as that may require
a force push and if I'm not mistaken force pushes are disabled in Apache
GIT.

thx


On Fri, Aug 1, 2014 at 4:43 PM, Karthik Kambatla <ka...@cloudera.com> wrote:

> Hi folks,
>
> From what I hear, a lot of devs use the git mirror for development/reviews
> and use subversion primarily for checking code in. I was wondering if it
> would make more sense just to move to git. In addition to subjective liking
> of git, I see the following advantages in our workflow:
>
>    1. Feature branches - it becomes easier to work on them and keep
>    rebasing against the latest trunk.
>    2. Cherry-picks between branches automatically ensures the exact same
>    commit message and tracks the lineage as well.
>    3. When cutting new branches and/or updating maven versions etc., it
>    allows doing all the work locally before pushing it to the main branch.
>    4. Opens us up to potentially using other code-review tools. (Gerrit?)
>    5. It is just more convenient.
>
> I am sure this was brought up before in different capacities. I believe the
> support for git in ASF is healthy now and several downstream projects have
> moved. Again, from what I hear, ASF INFRA folks make the migration process
> fairly easy.
>
> What do you all think?
>
> Thanks
> Karthik
>

Re: [DISCUSS] Migrate from svn to git for source control?

[Tsuyoshi OZAWA <oz...@gmail.com>]

Thank you for great suggestion, Karthik. +1(non-binding) to use git.
I'm also using private git repository.
Additionally, I have one question. Will we accept github-based
development like Apache Spark? IHMO, it allow us to leverage Hadoop
development, because the cost of sending pull request is very low and
its review board is great. One concern is that the development
workflow can change and it can confuse us. What do you think?

Thanks,
- Tsuyoshi

On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla <ka...@cloudera.com> wrote:
> Hi folks,
>
> From what I hear, a lot of devs use the git mirror for development/reviews
> and use subversion primarily for checking code in. I was wondering if it
> would make more sense just to move to git. In addition to subjective liking
> of git, I see the following advantages in our workflow:
>
>    1. Feature branches - it becomes easier to work on them and keep
>    rebasing against the latest trunk.
>    2. Cherry-picks between branches automatically ensures the exact same
>    commit message and tracks the lineage as well.
>    3. When cutting new branches and/or updating maven versions etc., it
>    allows doing all the work locally before pushing it to the main branch.
>    4. Opens us up to potentially using other code-review tools. (Gerrit?)
>    5. It is just more convenient.
>
> I am sure this was brought up before in different capacities. I believe the
> support for git in ASF is healthy now and several downstream projects have
> moved. Again, from what I hear, ASF INFRA folks make the migration process
> fairly easy.
>
> What do you all think?
>
> Thanks
> Karthik



-- 
- Tsuyoshi

RE: [DISCUSS] Migrate from svn to git for source control?

["Liu, Yi A" <yi...@intel.com>]

+1, Git is more convenient for development and we can switch easily between branches and can have local branches.

Regards,
Yi Liu


-----Original Message-----
From: Karthik Kambatla [mailto:kasha@cloudera.com] 
Sent: Saturday, August 02, 2014 7:44 AM
To: common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org
Subject: [DISCUSS] Migrate from svn to git for source control?

Hi folks,

From what I hear, a lot of devs use the git mirror for development/reviews and use subversion primarily for checking code in. I was wondering if it would make more sense just to move to git. In addition to subjective liking of git, I see the following advantages in our workflow:

   1. Feature branches - it becomes easier to work on them and keep
   rebasing against the latest trunk.
   2. Cherry-picks between branches automatically ensures the exact same
   commit message and tracks the lineage as well.
   3. When cutting new branches and/or updating maven versions etc., it
   allows doing all the work locally before pushing it to the main branch.
   4. Opens us up to potentially using other code-review tools. (Gerrit?)
   5. It is just more convenient.

I am sure this was brought up before in different capacities. I believe the support for git in ASF is healthy now and several downstream projects have moved. Again, from what I hear, ASF INFRA folks make the migration process fairly easy.

What do you all think?

Thanks
Karthik

Re: [DISCUSS] Migrate from svn to git for source control?

[Karthik Kambatla <ka...@cloudera.com>]

Personally, I would love us to use something like gerrit.

My current review workflow requires me to download the patch, apply it on
latest trunk and look at the diff in an IDE. I still might want to do it
for big patches, but I would love to be able to just see the diff directly.
Also, it would be nicer to look at the diff between versions. I understand
RB provides most of these, but I felt and heard gerrit is somehow better.

I am not sure using gerrit to commit to different branches is possible
though. I heard about other ASF projects getting resistance because it is a
headless user (gerrit) committing and not a person.


On Mon, Aug 4, 2014 at 9:54 AM, Alejandro Abdelnur <tu...@cloudera.com>
wrote:

> merging a multi jiras feature from one branch to another is much easier in
> git, you can keep all jiras as single commits, you can do any necessary
> rebasing locally, you cant tweak CHANGES.txt locally, tweak and rebase and
> squash as necessary, check everything locally, iterate, then push when
> things are ready.
>
> adopting gerrit would be gr8 too.
>
> thx
>
> Alejandro
> (phone typing)
>
> > On Aug 4, 2014, at 2:36, Steve Loughran <st...@hortonworks.com> wrote:
> >
> > I'm =0 on convenience, but like you said, that's because most people have
> > drifted into public/private git repos for development of branches (though
> > that's partly to avoid the ongoing review-before-each commit overhead)
> >
> > -moving to Git could encourage more in-ASF branch dev by committers
> > -if we adopt gerrit then code review would be significantly easier
> > -it'd reduce the latency from an svn commit to a git pull on the
> > git.apache.org repo
> > -we could take (compressed) "git am" patches with provenance. Other ASF
> > projects (Twill) do this.
> > -could maybe field git pull requests from outside
> >
> > I didn't think cherry picking did lineage so well, and svn merge does
> that
> > too. It's just a bit more fiddly.
> >
> > Given the overhead of actually applying patches to 2+ branches, I'm
> > grateful for anything that improves this.
> >
> > But...for a move to git, I'd like to see what the big gains are, which
> > seems to me to be in Gerrit.
> >
> >
> >
> >
> >
> >> On 2 August 2014 00:43, Karthik Kambatla <ka...@cloudera.com> wrote:
> >>
> >> Hi folks,
> >>
> >> From what I hear, a lot of devs use the git mirror for
> development/reviews
> >> and use subversion primarily for checking code in. I was wondering if it
> >> would make more sense just to move to git. In addition to subjective
> liking
> >> of git, I see the following advantages in our workflow:
> >>
> >>   1. Feature branches - it becomes easier to work on them and keep
> >>   rebasing against the latest trunk.
> >>   2. Cherry-picks between branches automatically ensures the exact same
> >>   commit message and tracks the lineage as well.
> >>   3. When cutting new branches and/or updating maven versions etc., it
> >>   allows doing all the work locally before pushing it to the main
> branch.
> >>   4. Opens us up to potentially using other code-review tools. (Gerrit?)
> >>   5. It is just more convenient.
> >>
> >> I am sure this was brought up before in different capacities. I believe
> the
> >> support for git in ASF is healthy now and several downstream projects
> have
> >> moved. Again, from what I hear, ASF INFRA folks make the migration
> process
> >> fairly easy.
> >>
> >> What do you all think?
> >>
> >> Thanks
> >> Karthik
> >
> > --
> > CONFIDENTIALITY NOTICE
> > NOTICE: This message is intended for the use of the individual or entity
> to
> > which it is addressed and may contain information that is confidential,
> > privileged and exempt from disclosure under applicable law. If the reader
> > of this message is not the intended recipient, you are hereby notified
> that
> > any printing, copying, dissemination, distribution, disclosure or
> > forwarding of this communication is strictly prohibited. If you have
> > received this communication in error, please contact the sender
> immediately
> > and delete it from your system. Thank You.
>

Re: [DISCUSS] Migrate from svn to git for source control?

[Sandy Ryza <sa...@cloudera.com>]

+1 to going with git, and +1 to a rebase flow if we do so.


On Mon, Aug 4, 2014 at 10:43 AM, Andrew Purtell <ap...@apache.org> wrote:

> HBase recently made the leap from SVN to Git. Our early experience is
> positive, I think. My observations:
>
> When you commit a merge in git, the software will generate a merge commit
> message in the target branch's history. HBasers decided these pollute
> history - although an option to 'git log' can elide them - so instead of
> using 'git merge' for merging we are using alternate workflows that build
> on 'git rebase'. Rebasing has sharper edges. Occasionally a committer will
> forget and we will have a merge commit in history. Now and then isn't much
> of an issue. As committers migrate from svn to git you will need to deal
> with the occasional botch in history, though. Git allows you to rewrite
> history but there are consequences to that and default protections in place
> to prevent it.
>
> Infra has something set up to protect against force pushing to certain
> protected branch names, such as "master" and "trunk". Otherwise you are
> able to force push by default. I think you will want to work with Infra to
> prevent force pushing to your branch-* branches as well. Conversely, a
> force push after rebasing a feature branch on trunk will not be an issue,
> if you exclude feature branches from this protection. That could be a good
> thing. If for some reason someone pushes toxic waste to a protected branch,
> it's easy to work with Infra to temporarily relax force push protections
> for cleanup. Finally, a force push will cause issues with any checkout
> tracking the old history, so you'll want to notify all committers in
> advance so they can take steps. This isn't an issue with SVN, so that's a
> consideration, but force pushes should be rare outside of feature branches
> (we haven't had one yet for ~months over in HBase).
>
> I found it convenient to tag a release candidate in SVN, then commit
> CHANGES.txt and other release specific modifications to the tag, since in
> SVN a tag is a branch is a tag, rather than mix release mechanics with the
> rest of branch history. This may be an unorthodox practice. I only mention
> it because with git tags don't work that way. I think it is possible to
> emulate this by pushing a temporary branch and the desired tag pointing to
> a commit on that branch, and then another push that removes the temporary
> branch, leaving only the tag as a ref to that part of history. If you like.
>
> We are having some minor discussions about commit formats, how we'd like to
> do contributor attribution. (This is my fault.) As with everything else
> about git, there are a couple of ways to do it.
>
>
> On Mon, Aug 4, 2014 at 9:54 AM, Alejandro Abdelnur <tu...@cloudera.com>
> wrote:
>
> > merging a multi jiras feature from one branch to another is much easier
> in
> > git, you can keep all jiras as single commits, you can do any necessary
> > rebasing locally, you cant tweak CHANGES.txt locally, tweak and rebase
> and
> > squash as necessary, check everything locally, iterate, then push when
> > things are ready.
> >
> > adopting gerrit would be gr8 too.
> >
> > thx
> >
> > Alejandro
> > (phone typing)
> >
> > > On Aug 4, 2014, at 2:36, Steve Loughran <st...@hortonworks.com>
> wrote:
> > >
> > > I'm =0 on convenience, but like you said, that's because most people
> have
> > > drifted into public/private git repos for development of branches
> (though
> > > that's partly to avoid the ongoing review-before-each commit overhead)
> > >
> > > -moving to Git could encourage more in-ASF branch dev by committers
> > > -if we adopt gerrit then code review would be significantly easier
> > > -it'd reduce the latency from an svn commit to a git pull on the
> > > git.apache.org repo
> > > -we could take (compressed) "git am" patches with provenance. Other ASF
> > > projects (Twill) do this.
> > > -could maybe field git pull requests from outside
> > >
> > > I didn't think cherry picking did lineage so well, and svn merge does
> > that
> > > too. It's just a bit more fiddly.
> > >
> > > Given the overhead of actually applying patches to 2+ branches, I'm
> > > grateful for anything that improves this.
> > >
> > > But...for a move to git, I'd like to see what the big gains are, which
> > > seems to me to be in Gerrit.
> > >
> > >
> > >
> > >
> > >
> > >> On 2 August 2014 00:43, Karthik Kambatla <ka...@cloudera.com> wrote:
> > >>
> > >> Hi folks,
> > >>
> > >> From what I hear, a lot of devs use the git mirror for
> > development/reviews
> > >> and use subversion primarily for checking code in. I was wondering if
> it
> > >> would make more sense just to move to git. In addition to subjective
> > liking
> > >> of git, I see the following advantages in our workflow:
> > >>
> > >>   1. Feature branches - it becomes easier to work on them and keep
> > >>   rebasing against the latest trunk.
> > >>   2. Cherry-picks between branches automatically ensures the exact
> same
> > >>   commit message and tracks the lineage as well.
> > >>   3. When cutting new branches and/or updating maven versions etc., it
> > >>   allows doing all the work locally before pushing it to the main
> > branch.
> > >>   4. Opens us up to potentially using other code-review tools.
> (Gerrit?)
> > >>   5. It is just more convenient.
> > >>
> > >> I am sure this was brought up before in different capacities. I
> believe
> > the
> > >> support for git in ASF is healthy now and several downstream projects
> > have
> > >> moved. Again, from what I hear, ASF INFRA folks make the migration
> > process
> > >> fairly easy.
> > >>
> > >> What do you all think?
> > >>
> > >> Thanks
> > >> Karthik
> > >
> > > --
> > > CONFIDENTIALITY NOTICE
> > > NOTICE: This message is intended for the use of the individual or
> entity
> > to
> > > which it is addressed and may contain information that is confidential,
> > > privileged and exempt from disclosure under applicable law. If the
> reader
> > > of this message is not the intended recipient, you are hereby notified
> > that
> > > any printing, copying, dissemination, distribution, disclosure or
> > > forwarding of this communication is strictly prohibited. If you have
> > > received this communication in error, please contact the sender
> > immediately
> > > and delete it from your system. Thank You.
> >
>
>
>
> --
> Best regards,
>
>    - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>

Re: [DISCUSS] Migrate from svn to git for source control?

[Alejandro Abdelnur <tu...@cloudera.com>]

neat, didn't know about the selective force push.


On Mon, Aug 4, 2014 at 10:43 AM, Andrew Purtell <ap...@apache.org> wrote:

> HBase recently made the leap from SVN to Git. Our early experience is
> positive, I think. My observations:
>
> When you commit a merge in git, the software will generate a merge commit
> message in the target branch's history. HBasers decided these pollute
> history - although an option to 'git log' can elide them - so instead of
> using 'git merge' for merging we are using alternate workflows that build
> on 'git rebase'. Rebasing has sharper edges. Occasionally a committer will
> forget and we will have a merge commit in history. Now and then isn't much
> of an issue. As committers migrate from svn to git you will need to deal
> with the occasional botch in history, though. Git allows you to rewrite
> history but there are consequences to that and default protections in place
> to prevent it.
>
> Infra has something set up to protect against force pushing to certain
> protected branch names, such as "master" and "trunk". Otherwise you are
> able to force push by default. I think you will want to work with Infra to
> prevent force pushing to your branch-* branches as well. Conversely, a
> force push after rebasing a feature branch on trunk will not be an issue,
> if you exclude feature branches from this protection. That could be a good
> thing. If for some reason someone pushes toxic waste to a protected branch,
> it's easy to work with Infra to temporarily relax force push protections
> for cleanup. Finally, a force push will cause issues with any checkout
> tracking the old history, so you'll want to notify all committers in
> advance so they can take steps. This isn't an issue with SVN, so that's a
> consideration, but force pushes should be rare outside of feature branches
> (we haven't had one yet for ~months over in HBase).
>
> I found it convenient to tag a release candidate in SVN, then commit
> CHANGES.txt and other release specific modifications to the tag, since in
> SVN a tag is a branch is a tag, rather than mix release mechanics with the
> rest of branch history. This may be an unorthodox practice. I only mention
> it because with git tags don't work that way. I think it is possible to
> emulate this by pushing a temporary branch and the desired tag pointing to
> a commit on that branch, and then another push that removes the temporary
> branch, leaving only the tag as a ref to that part of history. If you like.
>
> We are having some minor discussions about commit formats, how we'd like to
> do contributor attribution. (This is my fault.) As with everything else
> about git, there are a couple of ways to do it.
>
>
> On Mon, Aug 4, 2014 at 9:54 AM, Alejandro Abdelnur <tu...@cloudera.com>
> wrote:
>
> > merging a multi jiras feature from one branch to another is much easier
> in
> > git, you can keep all jiras as single commits, you can do any necessary
> > rebasing locally, you cant tweak CHANGES.txt locally, tweak and rebase
> and
> > squash as necessary, check everything locally, iterate, then push when
> > things are ready.
> >
> > adopting gerrit would be gr8 too.
> >
> > thx
> >
> > Alejandro
> > (phone typing)
> >
> > > On Aug 4, 2014, at 2:36, Steve Loughran <st...@hortonworks.com>
> wrote:
> > >
> > > I'm =0 on convenience, but like you said, that's because most people
> have
> > > drifted into public/private git repos for development of branches
> (though
> > > that's partly to avoid the ongoing review-before-each commit overhead)
> > >
> > > -moving to Git could encourage more in-ASF branch dev by committers
> > > -if we adopt gerrit then code review would be significantly easier
> > > -it'd reduce the latency from an svn commit to a git pull on the
> > > git.apache.org repo
> > > -we could take (compressed) "git am" patches with provenance. Other ASF
> > > projects (Twill) do this.
> > > -could maybe field git pull requests from outside
> > >
> > > I didn't think cherry picking did lineage so well, and svn merge does
> > that
> > > too. It's just a bit more fiddly.
> > >
> > > Given the overhead of actually applying patches to 2+ branches, I'm
> > > grateful for anything that improves this.
> > >
> > > But...for a move to git, I'd like to see what the big gains are, which
> > > seems to me to be in Gerrit.
> > >
> > >
> > >
> > >
> > >
> > >> On 2 August 2014 00:43, Karthik Kambatla <ka...@cloudera.com> wrote:
> > >>
> > >> Hi folks,
> > >>
> > >> From what I hear, a lot of devs use the git mirror for
> > development/reviews
> > >> and use subversion primarily for checking code in. I was wondering if
> it
> > >> would make more sense just to move to git. In addition to subjective
> > liking
> > >> of git, I see the following advantages in our workflow:
> > >>
> > >>   1. Feature branches - it becomes easier to work on them and keep
> > >>   rebasing against the latest trunk.
> > >>   2. Cherry-picks between branches automatically ensures the exact
> same
> > >>   commit message and tracks the lineage as well.
> > >>   3. When cutting new branches and/or updating maven versions etc., it
> > >>   allows doing all the work locally before pushing it to the main
> > branch.
> > >>   4. Opens us up to potentially using other code-review tools.
> (Gerrit?)
> > >>   5. It is just more convenient.
> > >>
> > >> I am sure this was brought up before in different capacities. I
> believe
> > the
> > >> support for git in ASF is healthy now and several downstream projects
> > have
> > >> moved. Again, from what I hear, ASF INFRA folks make the migration
> > process
> > >> fairly easy.
> > >>
> > >> What do you all think?
> > >>
> > >> Thanks
> > >> Karthik
> > >
> > > --
> > > CONFIDENTIALITY NOTICE
> > > NOTICE: This message is intended for the use of the individual or
> entity
> > to
> > > which it is addressed and may contain information that is confidential,
> > > privileged and exempt from disclosure under applicable law. If the
> reader
> > > of this message is not the intended recipient, you are hereby notified
> > that
> > > any printing, copying, dissemination, distribution, disclosure or
> > > forwarding of this communication is strictly prohibited. If you have
> > > received this communication in error, please contact the sender
> > immediately
> > > and delete it from your system. Thank You.
> >
>
>
>
> --
> Best regards,
>
>    - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>



-- 
Alejandro

Re: [DISCUSS] Migrate from svn to git for source control?

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

HBase recently made the leap from SVN to Git. Our early experience is
positive, I think. My observations:

When you commit a merge in git, the software will generate a merge commit
message in the target branch's history. HBasers decided these pollute
history - although an option to 'git log' can elide them - so instead of
using 'git merge' for merging we are using alternate workflows that build
on 'git rebase'. Rebasing has sharper edges. Occasionally a committer will
forget and we will have a merge commit in history. Now and then isn't much
of an issue. As committers migrate from svn to git you will need to deal
with the occasional botch in history, though. Git allows you to rewrite
history but there are consequences to that and default protections in place
to prevent it.

Infra has something set up to protect against force pushing to certain
protected branch names, such as "master" and "trunk". Otherwise you are
able to force push by default. I think you will want to work with Infra to
prevent force pushing to your branch-* branches as well. Conversely, a
force push after rebasing a feature branch on trunk will not be an issue,
if you exclude feature branches from this protection. That could be a good
thing. If for some reason someone pushes toxic waste to a protected branch,
it's easy to work with Infra to temporarily relax force push protections
for cleanup. Finally, a force push will cause issues with any checkout
tracking the old history, so you'll want to notify all committers in
advance so they can take steps. This isn't an issue with SVN, so that's a
consideration, but force pushes should be rare outside of feature branches
(we haven't had one yet for ~months over in HBase).

I found it convenient to tag a release candidate in SVN, then commit
CHANGES.txt and other release specific modifications to the tag, since in
SVN a tag is a branch is a tag, rather than mix release mechanics with the
rest of branch history. This may be an unorthodox practice. I only mention
it because with git tags don't work that way. I think it is possible to
emulate this by pushing a temporary branch and the desired tag pointing to
a commit on that branch, and then another push that removes the temporary
branch, leaving only the tag as a ref to that part of history. If you like.

We are having some minor discussions about commit formats, how we'd like to
do contributor attribution. (This is my fault.) As with everything else
about git, there are a couple of ways to do it.


On Mon, Aug 4, 2014 at 9:54 AM, Alejandro Abdelnur <tu...@cloudera.com>
wrote:

> merging a multi jiras feature from one branch to another is much easier in
> git, you can keep all jiras as single commits, you can do any necessary
> rebasing locally, you cant tweak CHANGES.txt locally, tweak and rebase and
> squash as necessary, check everything locally, iterate, then push when
> things are ready.
>
> adopting gerrit would be gr8 too.
>
> thx
>
> Alejandro
> (phone typing)
>
> > On Aug 4, 2014, at 2:36, Steve Loughran <st...@hortonworks.com> wrote:
> >
> > I'm =0 on convenience, but like you said, that's because most people have
> > drifted into public/private git repos for development of branches (though
> > that's partly to avoid the ongoing review-before-each commit overhead)
> >
> > -moving to Git could encourage more in-ASF branch dev by committers
> > -if we adopt gerrit then code review would be significantly easier
> > -it'd reduce the latency from an svn commit to a git pull on the
> > git.apache.org repo
> > -we could take (compressed) "git am" patches with provenance. Other ASF
> > projects (Twill) do this.
> > -could maybe field git pull requests from outside
> >
> > I didn't think cherry picking did lineage so well, and svn merge does
> that
> > too. It's just a bit more fiddly.
> >
> > Given the overhead of actually applying patches to 2+ branches, I'm
> > grateful for anything that improves this.
> >
> > But...for a move to git, I'd like to see what the big gains are, which
> > seems to me to be in Gerrit.
> >
> >
> >
> >
> >
> >> On 2 August 2014 00:43, Karthik Kambatla <ka...@cloudera.com> wrote:
> >>
> >> Hi folks,
> >>
> >> From what I hear, a lot of devs use the git mirror for
> development/reviews
> >> and use subversion primarily for checking code in. I was wondering if it
> >> would make more sense just to move to git. In addition to subjective
> liking
> >> of git, I see the following advantages in our workflow:
> >>
> >>   1. Feature branches - it becomes easier to work on them and keep
> >>   rebasing against the latest trunk.
> >>   2. Cherry-picks between branches automatically ensures the exact same
> >>   commit message and tracks the lineage as well.
> >>   3. When cutting new branches and/or updating maven versions etc., it
> >>   allows doing all the work locally before pushing it to the main
> branch.
> >>   4. Opens us up to potentially using other code-review tools. (Gerrit?)
> >>   5. It is just more convenient.
> >>
> >> I am sure this was brought up before in different capacities. I believe
> the
> >> support for git in ASF is healthy now and several downstream projects
> have
> >> moved. Again, from what I hear, ASF INFRA folks make the migration
> process
> >> fairly easy.
> >>
> >> What do you all think?
> >>
> >> Thanks
> >> Karthik
> >
> > --
> > CONFIDENTIALITY NOTICE
> > NOTICE: This message is intended for the use of the individual or entity
> to
> > which it is addressed and may contain information that is confidential,
> > privileged and exempt from disclosure under applicable law. If the reader
> > of this message is not the intended recipient, you are hereby notified
> that
> > any printing, copying, dissemination, distribution, disclosure or
> > forwarding of this communication is strictly prohibited. If you have
> > received this communication in error, please contact the sender
> immediately
> > and delete it from your system. Thank You.
>



-- 
Best regards,

   - Andy

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

Re: [DISCUSS] Migrate from svn to git for source control?

[Alejandro Abdelnur <tu...@cloudera.com>]

merging a multi jiras feature from one branch to another is much easier in git, you can keep all jiras as single commits, you can do any necessary rebasing locally, you cant tweak CHANGES.txt locally, tweak and rebase and squash as necessary, check everything locally, iterate, then push when things are ready. 

adopting gerrit would be gr8 too. 

thx

Alejandro
(phone typing)

> On Aug 4, 2014, at 2:36, Steve Loughran <st...@hortonworks.com> wrote:
> 
> I'm =0 on convenience, but like you said, that's because most people have
> drifted into public/private git repos for development of branches (though
> that's partly to avoid the ongoing review-before-each commit overhead)
> 
> -moving to Git could encourage more in-ASF branch dev by committers
> -if we adopt gerrit then code review would be significantly easier
> -it'd reduce the latency from an svn commit to a git pull on the
> git.apache.org repo
> -we could take (compressed) "git am" patches with provenance. Other ASF
> projects (Twill) do this.
> -could maybe field git pull requests from outside
> 
> I didn't think cherry picking did lineage so well, and svn merge does that
> too. It's just a bit more fiddly.
> 
> Given the overhead of actually applying patches to 2+ branches, I'm
> grateful for anything that improves this.
> 
> But...for a move to git, I'd like to see what the big gains are, which
> seems to me to be in Gerrit.
> 
> 
> 
> 
> 
>> On 2 August 2014 00:43, Karthik Kambatla <ka...@cloudera.com> wrote:
>> 
>> Hi folks,
>> 
>> From what I hear, a lot of devs use the git mirror for development/reviews
>> and use subversion primarily for checking code in. I was wondering if it
>> would make more sense just to move to git. In addition to subjective liking
>> of git, I see the following advantages in our workflow:
>> 
>>   1. Feature branches - it becomes easier to work on them and keep
>>   rebasing against the latest trunk.
>>   2. Cherry-picks between branches automatically ensures the exact same
>>   commit message and tracks the lineage as well.
>>   3. When cutting new branches and/or updating maven versions etc., it
>>   allows doing all the work locally before pushing it to the main branch.
>>   4. Opens us up to potentially using other code-review tools. (Gerrit?)
>>   5. It is just more convenient.
>> 
>> I am sure this was brought up before in different capacities. I believe the
>> support for git in ASF is healthy now and several downstream projects have
>> moved. Again, from what I hear, ASF INFRA folks make the migration process
>> fairly easy.
>> 
>> What do you all think?
>> 
>> Thanks
>> Karthik
> 
> -- 
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to 
> which it is addressed and may contain information that is confidential, 
> privileged and exempt from disclosure under applicable law. If the reader 
> of this message is not the intended recipient, you are hereby notified that 
> any printing, copying, dissemination, distribution, disclosure or 
> forwarding of this communication is strictly prohibited. If you have 
> received this communication in error, please contact the sender immediately 
> and delete it from your system. Thank You.

Re: [DISCUSS] Migrate from svn to git for source control?

[Steve Loughran <st...@hortonworks.com>]

I'm =0 on convenience, but like you said, that's because most people have
drifted into public/private git repos for development of branches (though
that's partly to avoid the ongoing review-before-each commit overhead)

-moving to Git could encourage more in-ASF branch dev by committers
-if we adopt gerrit then code review would be significantly easier
-it'd reduce the latency from an svn commit to a git pull on the
git.apache.org repo
-we could take (compressed) "git am" patches with provenance. Other ASF
projects (Twill) do this.
-could maybe field git pull requests from outside

I didn't think cherry picking did lineage so well, and svn merge does that
too. It's just a bit more fiddly.

Given the overhead of actually applying patches to 2+ branches, I'm
grateful for anything that improves this.

But...for a move to git, I'd like to see what the big gains are, which
seems to me to be in Gerrit.





On 2 August 2014 00:43, Karthik Kambatla <ka...@cloudera.com> wrote:

> Hi folks,
>
> From what I hear, a lot of devs use the git mirror for development/reviews
> and use subversion primarily for checking code in. I was wondering if it
> would make more sense just to move to git. In addition to subjective liking
> of git, I see the following advantages in our workflow:
>
>    1. Feature branches - it becomes easier to work on them and keep
>    rebasing against the latest trunk.
>    2. Cherry-picks between branches automatically ensures the exact same
>    commit message and tracks the lineage as well.
>    3. When cutting new branches and/or updating maven versions etc., it
>    allows doing all the work locally before pushing it to the main branch.
>    4. Opens us up to potentially using other code-review tools. (Gerrit?)
>    5. It is just more convenient.
>
> I am sure this was brought up before in different capacities. I believe the
> support for git in ASF is healthy now and several downstream projects have
> moved. Again, from what I hear, ASF INFRA folks make the migration process
> fairly easy.
>
> What do you all think?
>
> Thanks
> Karthik
>

-- 
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to 
which it is addressed and may contain information that is confidential, 
privileged and exempt from disclosure under applicable law. If the reader 
of this message is not the intended recipient, you are hereby notified that 
any printing, copying, dissemination, distribution, disclosure or 
forwarding of this communication is strictly prohibited. If you have 
received this communication in error, please contact the sender immediately 
and delete it from your system. Thank You.

Re: [DISCUSS] Migrate from svn to git for source control?

[Andrew Wang <an...@cloudera.com>]

Thanks for starting this thread Karthik! Big +1 from me. I only use svn
when I have to commit things or work on the site, otherwise it's always the
git mirror or local git repos.

Considering that the git mirror works as well as it does, I'd expect this
to be a pretty smooth transition.

Best,
Andrew


On Fri, Aug 1, 2014 at 4:43 PM, Karthik Kambatla <ka...@cloudera.com> wrote:

> Hi folks,
>
> From what I hear, a lot of devs use the git mirror for development/reviews
> and use subversion primarily for checking code in. I was wondering if it
> would make more sense just to move to git. In addition to subjective liking
> of git, I see the following advantages in our workflow:
>
>    1. Feature branches - it becomes easier to work on them and keep
>    rebasing against the latest trunk.
>    2. Cherry-picks between branches automatically ensures the exact same
>    commit message and tracks the lineage as well.
>    3. When cutting new branches and/or updating maven versions etc., it
>    allows doing all the work locally before pushing it to the main branch.
>    4. Opens us up to potentially using other code-review tools. (Gerrit?)
>    5. It is just more convenient.
>
> I am sure this was brought up before in different capacities. I believe the
> support for git in ASF is healthy now and several downstream projects have
> moved. Again, from what I hear, ASF INFRA folks make the migration process
> fairly easy.
>
> What do you all think?
>
> Thanks
> Karthik
>

Re: [DISCUSS] Migrate from svn to git for source control?

[Henry Saputra <he...@gmail.com>]

+1 for this =)

Been using Github mirror for development anyway =)

We at Apache Gora moved to Git recently and it had been pretty smooth
transition.

- Henry

On Fri, Aug 1, 2014 at 4:43 PM, Karthik Kambatla <ka...@cloudera.com> wrote:
> Hi folks,
>
> From what I hear, a lot of devs use the git mirror for development/reviews
> and use subversion primarily for checking code in. I was wondering if it
> would make more sense just to move to git. In addition to subjective liking
> of git, I see the following advantages in our workflow:
>
>    1. Feature branches - it becomes easier to work on them and keep
>    rebasing against the latest trunk.
>    2. Cherry-picks between branches automatically ensures the exact same
>    commit message and tracks the lineage as well.
>    3. When cutting new branches and/or updating maven versions etc., it
>    allows doing all the work locally before pushing it to the main branch.
>    4. Opens us up to potentially using other code-review tools. (Gerrit?)
>    5. It is just more convenient.
>
> I am sure this was brought up before in different capacities. I believe the
> support for git in ASF is healthy now and several downstream projects have
> moved. Again, from what I hear, ASF INFRA folks make the migration process
> fairly easy.
>
> What do you all think?
>
> Thanks
> Karthik