The "git" way of doing things would be to rebase the feature branch on master (trunk) and then commit the patch stack.
Squashing the entire feature into a 10 MB megapatch is the "svn" way of doing things. The svn workflow evolved because merging feature branches back to trunk was really painful in svn. So people preferred just to basically do an rsync from a checkout of the feature branch, edit that up a bit to make sure they weren't overwriting something that happened in trunk, and then do an "svn commit" that did not tie back to the feature branch. P.S. Merges were so painful in SVN that some of the organizations I worked for maintained spreadsheets of patches which had been merged to each branch, since svn was of so little help with merging P.P.S. svn eventually got slightly smarter about merges -- I think in svn 1.6 or something? Colin On Wed, Aug 30, 2017, at 14:37, Sangjin Lee wrote: > I recall this discussion about a couple of years ago: > https://lists.apache.org/thread.html/43cd65c6b6c3c0e8ac2b3c76afd9eff1f78b177fabe9c4a96d9b3d0b@1440189889@%3Ccommon-dev.hadoop.apache.org%3E > > On Wed, Aug 30, 2017 at 2:32 PM, Steve Loughran <ste...@hortonworks.com> > wrote: > > > I'd have assumed it would have gone in as one single patch, rather than a > > full history. I don't see why the trunk needs all the evolutionary history > > of a build. > > > > What should our policy/process be here? > > > > I do currently plan to merge the s3guard in as one single squashed patch; > > just getting HADOOP-14809 sorted first. > > > > > > > On 30 Aug 2017, at 07:09, Vrushali C <vrushalic2...@gmail.com> wrote: > > > > > > I'm adding my +1 (binding) to conclude the vote. > > > > > > With 13 +1's (11 binding) and no -1's, the vote passes. We'll get on with > > > the merge to trunk shortly. Thanks everyone! > > > > > > Regards > > > Vrushali > > > > > > > > > On Tue, Aug 29, 2017 at 10:54 AM, varunsax...@apache.org < > > > varun.saxena.apa...@gmail.com> wrote: > > > > > >> +1 (binding). > > >> > > >> Kudos to all the team members for their great work! > > >> > > >> Being part of the ATSv2 team, I have been involved with either > > development > > >> or review of most of the JIRAs'. > > >> Tested ATSv2 in both secure and non-secure mode. Also verified that > > there > > >> is no impact when ATSv2 is turned off. > > >> > > >> Regards, > > >> Varun Saxena. > > >> > > >> On Tue, Aug 22, 2017 at 12:02 PM, Vrushali Channapattan < > > >> vrushalic2...@gmail.com> wrote: > > >> > > >>> Hi folks, > > >>> > > >>> Per earlier discussion [1], I'd like to start a formal vote to merge > > >>> feature branch YARN-5355 [2] (Timeline Service v.2) to trunk. The vote > > >>> will > > >>> run for 7 days, and will end August 29 11:00 PM PDT. > > >>> > > >>> We have previously completed one merge onto trunk [3] and Timeline > > Service > > >>> v2 has been part of Hadoop release 3.0.0-alpha1. > > >>> > > >>> Since then, we have been working on extending the capabilities of > > Timeline > > >>> Service v2 in a feature branch [2] for a while, and we are reasonably > > >>> confident that the state of the feature meets the criteria to be merged > > >>> onto trunk and we'd love folks to get their hands on it in a test > > capacity > > >>> and provide valuable feedback so that we can make it production-ready. > > >>> > > >>> In a nutshell, Timeline Service v.2 delivers significant scalability > > and > > >>> usability improvements based on a new architecture. What we would like > > to > > >>> merge to trunk is termed "alpha 2" (milestone 2). The feature has a > > >>> complete end-to-end read/write flow with security and read level > > >>> authorization via whitelists. You should be able to start setting it up > > >>> and > > >>> testing it. > > >>> > > >>> At a high level, the following are the key features that have been > > >>> implemented since alpha1: > > >>> - Security via Kerberos Authentication and delegation tokens > > >>> - Read side simple authorization via whitelist > > >>> - Client configurable entity sort ordering > > >>> - Richer REST APIs for apps, app attempts, containers, fetching > > metrics by > > >>> timerange, pagination, sub-app entities > > >>> - Support for storing sub-application entities (entities that exist > > >>> outside > > >>> the scope of an application) > > >>> - Configurable TTLs (time-to-live) for tables, configurable table > > >>> prefixes, > > >>> configurable hbase cluster > > >>> - Flow level aggregations done as dynamic (table level) coprocessors > > >>> - Uses latest stable HBase release 1.2.6 > > >>> > > >>> There are a total of 82 subtasks that were completed as part of this > > >>> effort. > > >>> > > >>> We paid close attention to ensure that once disabled Timeline Service > > v.2 > > >>> does not impact existing functionality when disabled (by default). > > >>> > > >>> Special thanks to a team of folks who worked hard and contributed > > towards > > >>> this effort with patches, reviews and guidance: Rohith Sharma K S, > > Varun > > >>> Saxena, Haibo Chen, Sangjin Lee, Li Lu, Vinod Kumar Vavilapalli, Joep > > >>> Rottinghuis, Jason Lowe, Jian He, Robert Kanter, Micheal Stack. > > >>> > > >>> Regards, > > >>> Vrushali > > >>> > > >>> [1] http://www.mail-archive.com/yarn-dev@hadoop.apache.org/ > > msg27383.html > > >>> [2] https://issues.apache.org/jira/browse/YARN-5355 > > >>> [3] https://issues.apache.org/jira/browse/YARN-2928 > > >>> [4] https://github.com/apache/hadoop/commits/YARN-5355 > > >>> > > >> > > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org > > For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
