+1, -Vinay On Aug 24, 2015 11:29 PM, "Colin P. McCabe" <cmcc...@apache.org> wrote:
> +1 > > cheers, > Colin > > On Mon, Aug 24, 2015 at 10:04 AM, Steve Loughran <ste...@hortonworks.com> > wrote: > > +1 (binding) > > > >> On 21 Aug 2015, at 13:44, Andrew Wang <andrew.w...@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 > > >
