hadoop-yarn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karthik Kambatla <ka...@cloudera.com>
Subject Re: [DISCUSS] Migrate from svn to git for source control?
Date Wed, 06 Aug 2014 21:16:15 GMT
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 <andrew.wang@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 <aagarwal@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 <tucu00@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.
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message