Hey Anna,
On my side: +1 if it helps your development efforts, and if the feature branch won't be a "long living" one. (and of course you would merge it with the trunk frequently not to let it diverge too much from other changes). Related actions (by me): I would like to support your efforts on this side by finalizing the 1.4.7 release dates with the community soon (I'd like to send an email about those efforts still today). On request: Would you please enlist the JIRA tasks you'd like to work on related to that specific feature branch (thus the whole community would be able to see the scope of the features you'd working on). Cheers, Attila On Fri, May 12, 2017 at 11:58 AM, Anna Szonyi <szo...@cloudera.com> wrote: > Hi @devs, > > We would like to start the preparation for upgrading to hive 2 (upgrade > version, migrate off of hive cli and onto beeline, etc.). > As we anticipate there being a few patches we were thinking it would make > sense to create a feature branch (sqoop_hive2) for this, as we do not want > trunk to become unstable or introduce "breaking changes" before the > proposed 1.4.7 release. > > Does anyone have any concerns about this? > > And in general do we have a policy about feature branches for sqoop (like a > sqoop_kerberos branch, etc.)? > > Thanks, > Anna >
