hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Wang <andrew.w...@cloudera.com>
Subject Re: [VOTE] Using rebase and merge for feature branch development
Date Tue, 01 Sep 2015 22:06:58 GMT
With I believe 9 +1s (7 binding), the vote passes. Thanks all for voting
and the very helpful discussion, I'll file a JIRA and get this content in a
more accessible place.

Best,
Andrew

On Tue, Aug 25, 2015 at 10:22 AM, Sangjin Lee <sjlee0@gmail.com> wrote:

> +1 (non-binding).
>
> Thanks,
> Sangjin
>
> On Tue, Aug 25, 2015 at 10:13 AM, Ravi Prakash <ravihoo@ymail.com> wrote:
>
> > +1. Thanks
> >
> >
> >
> >      On Monday, August 24, 2015 3:02 PM, Jing Zhao <jing9@apache.org>
> > wrote:
> >
> >
> >  +1. Thanks.
> >
> > On Mon, Aug 24, 2015 at 2:47 PM, Zhe Zhang <zhezhang@cloudera.com>
> wrote:
> >
> > > +1 non-binding. Thanks Andrew!
> > >
> > > ---
> > > Zhe Zhang
> > >
> > > On Mon, Aug 24, 2015 at 2:38 PM, Karthik Kambatla <kasha@cloudera.com>
> > > wrote:
> > >
> > > > +1
> > > >
> > > > Thanks for driving this, Andrew.
> > > >
> > > > On Mon, Aug 24, 2015 at 11:00 AM, Vinayakumar B <
> > vinayakumarb@apache.org
> > > >
> > > > wrote:
> > > >
> > > > > +1,
> > > > >
> > > > > -Vinay
> > > > > On Aug 24, 2015 11:29 PM, "Colin P. McCabe" <cmccabe@apache.org>
> > > wrote:
> > > > >
> > > > > > +1
> > > > > >
> > > > > > cheers,
> > > > > > Colin
> > > > > >
> > > > > > On Mon, Aug 24, 2015 at 10:04 AM, Steve Loughran <
> > > > stevel@hortonworks.com
> > > > > >
> > > > > > wrote:
> > > > > > > +1 (binding)
> > > > > > >
> > > > > > >> On 21 Aug 2015, at 13:44, Andrew Wang <
> andrew.wang@cloudera.com
> > >
> > > > > wrote:
> > > > > > >>
> > > > > > >> Hi common-dev,
> > > > > > >>
> > > > > > >> As promised, here is an official vote thread. Let's
run it for
> > the
> > > > > > standard
> > > > > > >> 7 days, closing on Aug 28th at noon. Only PMC members
have
> > binding
> > > > > > votes,
> > > > > > >> but of course everyone's input is welcomed.
> > > > > > >>
> > > > > > >> If the vote passes, I'll put the text on the website
somewhere
> > as
> > > > > > >> recommended by Steve.
> > > > > > >>
> > > > > > >> Previous discussion threads:
> > > > > > >>
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
> http://mail-archives.apache.org/mod_mbox/hadoop-common-dev/201508.mbox/%3CCAGB5D2bPWeV2Hk%2B67%3DDamWpVfLTM6nkjb_wG3n4%3DWAN890zqfA%40mail.gmail.com%3E
> > > > > > >>
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
> http://mail-archives.apache.org/mod_mbox/hadoop-common-dev/201508.mbox/%3CCAGB5D2aDXujQjwdmadVtg2-qrPAJeOgCS2_NHydv8jke8or1UA%40mail.gmail.com%3E
> > > > > > >>
> > > > > > >> Proposal:
> > > > > > >>
> > > > > > >> ====
> > > > > > >>
> > > > > > >> Feature branch development can use either a merge or
rebase
> > > > workflow,
> > > > > as
> > > > > > >> decided by contributors working on the branch.
> > > > > > >>
> > > > > > >> When using a rebase workflow, the feature branch is
> periodically
> > > > > > rebased on
> > > > > > >> trunk via "git rebase trunk" and force pushed.
> > > > > > >>
> > > > > > >> Before performing a force-push, a tag should be created
of the
> > > > current
> > > > > > >> feature branch HEAD to preserve history. The tag should
> identify
> > > the
> > > > > > >> feature and date of most recent commit, e.g.
> > > > > > >> "tag_feature_HDFS-7285_2015-08-11". It can also be
convenient
> to
> > > > use a
> > > > > > >> temporary branch to review rebase conflict resolution
before
> > > > > > force-pushing
> > > > > > >> the main feature branch, e.g. HDFS-7285-rebase. Temporary
> > branches
> > > > > > should
> > > > > > >> be deleted after they are force-pushed over the feature
> branch.
> > > > > > >>
> > > > > > >> Developers are allowed to squash and reorder commits
to make
> > > > rebasing
> > > > > > >> easier. Use this judiciously. When squashing, please
maintain
> > the
> > > > > > original
> > > > > > >> commit messages in the squashed commit message to preserve
> > > history.
> > > > > > >>
> > > > > > >> When using a merge workflow, changes are periodically
> integrated
> > > > from
> > > > > > trunk
> > > > > > >> to the branch via "git merge trunk".
> > > > > > >>
> > > > > > >> Merge conflict resolution can be reviewed by posting
the diff
> of
> > > the
> > > > > > merge
> > > > > > >> commit.
> > > > > > >>
> > > > > > >> For both rebase and merge workflows, integration of
the branch
> > > into
> > > > > > trunk
> > > > > > >> should happen via "git merge --no-ff". "--no-ff" is
important
> > > since
> > > > it
> > > > > > >> generates a merge commit even if the branch applies
cleanly on
> > top
> > > > of
> > > > > > >> trunk. This clearly denotes the set of commits that
were made
> on
> > > the
> > > > > > >> branch, and makes it easier to revert the branch if
necessary.
> > > > > > >>
> > > > > > >> "git merge --no-ff" is also the preferred way of integrating
a
> > > > feature
> > > > > > >> branch to other branches, e.g. branch-2.
> > > > > > >>
> > > > > > >> ====
> > > > > > >>
> > > > > > >> Thanks,
> > > > > > >> Andrew
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> >
>

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