Thanks for the detailed pointers Gwen. I understand your concerns better
now. My understanding from these threads as well as what you have described
is that the confusion you refer to stems from the fact that Sqoop2 is not
at feature parity with Sqoop(1) yet.

It will be great to *discuss* what are the various ways to address this and
then call a vote to decide upon the approach to use. Some other approaches
that I can suggest are:

1. Calling Sqoop1 explicitly as "stable" in our downloads section, or even
within the release label. So instead of Sqoop-1.4.5, it would be

2. Alternatively calling Sqoop2 explicitly "alpha", "beta" or
"experimental". Eg - Sqoop-1.99.4 would become Sqoop-1.99.4-beta.

3. Or perhaps a combination of both of these.

4. Plus good UI messaging that clearly outlines the critical differences
between these to products.

Personally, I do not believe that having a code name will solve the issue
at hand, and may even make it worse. If the motivation is to call out
Sqoop2 as something "not-Sqoop", then perhaps we should discuss the
viability of this branch effort. If we conclude that it is not going to
progress any further, we could call a vote on discontinuing this effort and
instead focusing on the main Sqoop1 branch alone.

Hope you understand my point of view on this.

Arvind Prabhakar
On Fri, Jul 25, 2014 at 10:53 AM, Gwen Shapira <[EMAIL PROTECTED]>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB