Hi all, I also like the idea of creating feature branches. As far as I see we cannot create Sqoop epics on issues.apache.org so we could use subtasks to track what do we plan to put in a feature branch.
Regards, Szabolcs On Fri, May 12, 2017 at 2:15 PM, Attila Szabó <mau...@apache.org> wrote: > 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 > > > -- Szabolcs Vasas Software Engineer <http://www.cloudera.com>
