I would like to see an addition to the note that says: Latest stable release is 1.4.4 (download, documentation). Latest experimental release is 1.99.3 (download, documentation) - Note that 1.99.3 is not compatible with 1.4.4 and not feature complete, it is not intended for production deployment.
Or something along those lines - basically the I would like to see the phrase "not for production deployment" in there somewhere. -----Original Message----- From: Gwen Shapira [mailto:gshap...@cloudera.com] Sent: Tuesday, 12 August 2014 2:20 AM To: dev@sqoop.apache.org Subject: Re: Discussing solutions to Sqoop1 and Sqoop2 confusion (was: Code name for Sqoop 2) Thanks to everyone contributing to the discussion. I think it makes sense to mark Sqoop2 as Sqoop-1.99.3-prerelease and make our site a bit clearer about its lack of backward compatibility. If this doesn't help - we can re-visit the rename idea. How about taking the following steps: - Change the blurb on our front page from: "Latest stable release is 1.4.4 (download, documentation). Latest cut of Sqoop2 is 1.99.3 (download, documentation)." to: "Latest stable release is 1.4.4 (download, documentation). Latest experimental release is 1.99.3 (download, documentation) - Note that 1.99.3 is not compatible with 1.4.4 and not feature complete." - Change all references to 1.99.3 to "1.99.3-prerelease" - Add clarifications in Sqoop2 docs that Sqoop1 parameters and connectors are not supported. - I'd like to also change the name of our Sqoop2 shell client to something less confusing, but can't think of anything good here :) What do you think? Gwen On Fri, Aug 8, 2014 at 4:17 PM, Kathleen Ting <kathl...@apache.org> wrote: > Agreed with David and Arvind that codenames can be confusing to new users. > > +1 on option 4 which is a combination of the following: > (a) following Apache Hadoop precedence and calling it > Sqoop-1.99.3-prerelease > (b) putting a disclaimer that Sqoop-1.99.3-prerelease is not intended > for production deployment on its download link > (c) using explicit UI messaging to warn Sqoop-1.99.3-prerelease users > that it does not have feature parity with Sqoop1 > > On Fri, Aug 1, 2014 at 6:39 PM, David Robson > <david.rob...@software.dell.com> wrote: >> So it seems like the problem we are trying to solve is for a new user, they >> download Sqoop 1.99.3 - have bad experiences because it is still >> experimental (based on recent mail threads this may put them off Sqoop for >> good). So we should make it as easy as possible to download the correct >> version of Sqoop for them. >> >> I believe for a new user - codenames cause more confusion. Assuming a user >> knew nothing about Sqoop and was given the choice of Sqoop 1.4.5 or Sqoop >> Pelican - how would they know which one to choose? Now if they were given >> the choice of Sqoop 1.4.5 or Sqoop 1.99.3-alpha - it would be much more >> obvious. Of course either way you could put some text on the homepage / >> download page explaining the two releases which should be done either way. >> >> I don't think we should add to the confusion by bringing in codenames - and >> instead stick with the industry standard alpha / beta / stable terminology >> as Arvind suggested. >> >> So I would vote on option 2 - and we should put a warning like "not intended >> for production deployment" on the link to download Sqoop 1.99.3-alpha. >> >> -----Original Message----- >> From: Abraham Elmahrek [mailto:a...@cloudera.com] >> Sent: Saturday, 2 August 2014 6:01 AM >> To: dev@sqoop.apache.org >> Subject: Re: Discussing solutions to Sqoop1 and Sqoop2 confusion >> (was: Code name for Sqoop 2) >> >> +1 for proposal 1 as well. >> >> >> On Fri, Aug 1, 2014 at 11:46 AM, Venkat Ranganathan < >> vranganat...@hortonworks.com> wrote: >> >>> +1 for propsal 1 also >>> >>> Thanks >>> >>> Venkat >>> >>> On Fri, Aug 1, 2014 at 9:38 AM, Jarek Jarcec Cecho >>> <jar...@apache.org> >>> wrote: >>> > I don’t have any other suggestion either, so let’s discuss which >>> > one >>> would people prefer? >>> > >>> > I’m personally in favor of proposal 1). >>> > >>> > Jarcec >>> > >>> > On Jul 28, 2014, at 10:04 AM, Gwen Shapira <gshap...@cloudera.com> >>> wrote: >>> > >>> >> Thanks for the great summary. I don't have additional suggestions. >>> >> >>> >> Gwen >>> >> >>> >> On Sun, Jul 27, 2014 at 11:03 AM, Arvind Prabhakar >>> >> <arv...@apache.org> >>> wrote: >>> >>> Thanks Gwen and Jarcec. It appears that we all agree to the few >>> >>> basic points below: >>> >>> >>> >>> a) Sqoop2 is promising effort although not near completion. We >>> >>> agree >>> that >>> >>> there is no need to discuss shutting that down at this time. >>> >>> b) The naming of Sqoop2 is such that it raises expectations in >>> >>> users/adopters to be better than Sqoop(1) and thus leads to confusion. >>> >>> >>> >>> The second point (b) above is the key issue that needs resolution. >>> >>> The options discussed thus far are as follows: >>> >>> >>> >>> 1. Put a code name for Sqoop2 so that it is not confused with Sqoop(1). >>> >>> This seems to have good community support. >>> >>> 2. Use a explicit labels such as "stable" vs "beta/alpha/experimental" >>> for >>> >>> various Sqoop releases. >>> >>> 3. Use explicit UI messaging to warn Sqoop2 users that it is not >>> >>> the >>> same >>> >>> as Sqoop(1) and is far behind on feature completeness and stability. >>> There >>> >>> seems to be some concerns around how this can be done given the >>> >>> client/server architecture of Sqoop2. >>> >>> 4. A combination of options 2 and 3 above. >>> >>> >>> >>> Are there any suggestions to mitigate this problem? Perhaps we >>> >>> should cross-post this thread to user list as well to see if >>> >>> they agree with >>> the >>> >>> options here and/or if they have any other suggestions. >>> >>> >>> >>> Regards, >>> >>> Arvind Prabhakar >>> >>> >>> >>> >>> >>> >>> >>> On Sat, Jul 26, 2014 at 6:50 PM, Jarek Jarcec Cecho >>> >>> <jar...@apache.org >>> > >>> >>> wrote: >>> >>> >>> >>>> Hi Arvind, >>> >>>> thank you very much for sharing your concerns! You’ve risen a >>> >>>> very >>> good >>> >>>> points. >>> >>>> >>> >>>> I personally see value in Sqoop 2 as the new architecture will >>> >>>> allow >>> us to >>> >>>> cover much more use cases, various compliancy regulations and >>> >>>> will eventually simplify user’s life. Based on the recent >>> >>>> increase in dev activity, it seems that I’m not the only one >>> >>>> who do believes in that >>> and >>> >>>> hence I strongly believe that discontinuing the effort doesn’t >>> >>>> seem >>> as the >>> >>>> right way to go. I’m more then happy to discuss this topic >>> >>>> further if >>> you >>> >>>> believe that it’s the right way though. >>> >>>> >>> >>>> Having said that I do believe in Sqoop 2, I have to second Gwen >>> >>>> that current situation is very confusing to our users. I’ve >>> >>>> seen >>> significant >>> >>>> number of users confused about why 1.99.4 do not have >>> >>>> Avro/HBase/Hive integration when Sqoop 1 already have that. I >>> >>>> was anticipating the confusion and hence I’ve suggested to use >>> >>>> version number 1.99.x >>> instead of >>> >>>> 2.0.0 back when we were working on getting the first cut out of >>> >>>> the >>> door. I >>> >>>> hoped that version 1.99.x will make obvious to everybody that >>> >>>> it’s not “2.0.0” quite yet. Sadly it seems that this alone did >>> >>>> not helped as >>> much as >>> >>>> I hoped. >>> >>>> >>> >>>> Hence I do see value in changing our public messaging as you’ve >>> suggested >>> >>>> to make the message more clearer. I personally like the idea >>> >>>> with >>> code name >>> >>>> as that is quite popular in other projects and companies >>> >>>> (remember >>> Windows >>> >>>> Longorn?) and it seems to be conveying the message. I do see a >>> >>>> lot of variability of using that code name though - I don’t >>> >>>> think that we necessarily have to remove any possible reference >>> >>>> to “Sqoop 2” from >>> the >>> >>>> face of earth. I believe that the code name is very well suited >>> >>>> for >>> our >>> >>>> webpage, wiki and perhaps a blog posts to make obvious that >>> >>>> there is >>> just >>> >>>> one single stable Sqoop version and then some ongoing effort >>> >>>> that do >>> have >>> >>>> available several cuts. I believe that just by doing that we >>> >>>> will >>> decrease >>> >>>> confusion about what version should user download and use. We >>> >>>> can >>> discuss >>> >>>> to what extent we want to push the code name and to what extent >>> >>>> we >>> will >>> >>>> keep the reference to “Sqoop 2”. After all I’m confident that >>> >>>> in not >>> too >>> >>>> distant future, we will have Sqoop 2 that will offer the >>> >>>> comparable capability and features as Sqoop 1. >>> >>>> >>> >>>> I don’t think that the code name is the only idea that will >>> >>>> decrease >>> the >>> >>>> immediate user confusion and hence I’m happy to hear others thoughts! >>> >>>> >>> >>>> Jarcec >>> >>>> >>> >>>> On Jul 26, 2014, at 6:00 PM, Gwen Shapira >>> >>>> <gshap...@cloudera.com> >>> wrote: >>> >>>> >>> >>>>> Thanks Arvind for your detailed explanation. >>> >>>>> >>> >>>>> I agree that naming releases stable and alpha is a good idea. >>> >>>>> I don't agree that it will solve the issue, but we can't know until >>> >>>>> we try. >>> >>>>> >>> >>>>> Considering that Sqoop2 is intentionally a client-server >>> >>>>> architecture with multiple clients and a REST API as an >>> >>>>> additional access point, I believe that it is not feasible to mark UI >>> >>>>> as beta. >>> >>>>> >>> >>>>> I want to stress that I personally believe that Sqoop2 is a >>> >>>>> very viable branch effort, to the extent that I am actively >>> >>>>> contributing >>> to >>> >>>>> it. >>> >>>>> As Sqoop2 becomes more and more viable alternative to Sqoop1, >>> >>>>> we need to prepare, as a community, to support both versions. >>> >>>>> >>> >>>>> Considering the number of features currently in Sqoop1 and the >>> >>>>> number of production Sqoop1 users, I can see us supporting >>> >>>>> both versions for the next 2 years. Making it easy for the >>> >>>>> community to support both is my top concern here. Having to >>> >>>>> resolve endless confusions for two years doesn't seem like a >>> >>>>> happy future to me. I see the Python community fighting the >>> >>>>> same issue since they broke compatibility between versions 2 >>> >>>>> and 3. I'd like to see us learn from those >>> mistakes >>> >>>>> and do better. >>> >>>>> >>> >>>>> I agree that a discussion would have been better than a vote. >>> >>>>> I was under the mistaken impression that there is a consensus >>> >>>>> on the >>> matter. >>> >>>>> I renamed the thread to make it clear that we are interested >>> >>>>> in hearing opinions from the rest of the community on this subject. >>> >>>>> >>> >>>>> >>> >>>>> Bike-sheddingly yours, >>> >>>>> >>> >>>>> Gwen Shapira >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> On Sat, Jul 26, 2014 at 4:44 PM, Arvind Prabhakar >>> >>>>> <arv...@apache.org >>> > >>> >>>> wrote: >>> >>>>>> 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 Sqoop-1.4.5-stable. >>> >>>>>> >>> >>>>>> 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. >>> >>>>>> >>> >>>>>> Regards, >>> >>>>>> Arvind Prabhakar >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> On Fri, Jul 25, 2014 at 10:53 AM, Gwen Shapira < >>> gshap...@cloudera.com> >>> >>>>>> wrote: >>> >>>>>> >>> >>>>>>> Hi Arvind, >>> >>>>>>> >>> >>>>>>> Here are few more threads from the last month where we had >>> >>>>>>> to >>> explain >>> >>>>>>> Sqoop2 status or explain that you can't use "sqoop import" >>> >>>>>>> with Sqoop2, etc: >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>> >>> http://mail-archives.apache.org/mod_mbox/sqoop-user/201407.mbox/%3CC >>> A% >>> 2BP7NPNTFuPYqf74M5OFw4e9xKZm2ns%3DZ0ydkkuJ06Jcg31hnw%40mail.gmail.co >>> m% >>> 3E >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>> >>> http://mail-archives.apache.org/mod_mbox/sqoop-user/201407.mbox/%3CC >>> AA >>> J8D%3D9Ho%3DYH7jdavNAb1gwz19Z5dapmS98yR71KmM5LsjCEVw%40mail.gmail.co >>> m% >>> 3E >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>> >>> http://mail-archives.apache.org/mod_mbox/sqoop-user/201407.mbox/%3CC >>> AP >>> wc21YtdgAm9jO3%2Bs0asBZ2JkG%3DVCp5PLpkO5xQuuBPKQGuTw%40mail.gmail.co >>> m% >>> 3E >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>> >>> http://mail-archives.apache.org/mod_mbox/sqoop-user/201406.mbox/%3CC >>> AO >>> rS3pxWuxL1X9Sb816N_o1Jd==gs9ww6uje2po+fpaw7vh...@mail.gmail.com%3E >>> >>>>>>> >>> >>>>>>> In addition, I noticed the problem when talking to users in >>> >>>>>>> conferences, customers, members of support team, etc (not to >>> mention >>> >>>>>>> that I got confused personally when I started out.) I didn't >>> >>>>>>> bring much evidence in my first email because I thought >>> there >>> >>>>>>> was a wide consensus about the problem. >>> >>>>>>> >>> >>>>>>> I have several goals with the code-name: >>> >>>>>>> >>> >>>>>>> * We need to remove the impression that the new version is >>> >>>>>>> like >>> Sqoop >>> >>>>>>> only better. It is only somewhat like Sqoop and will not be >>> strictly >>> >>>>>>> better for many months yet. >>> >>>>>>> * We need to clarify that this project is not even close to >>> production >>> >>>>>>> quality. >>> >>>>>>> * We need to make it easy for us to quickly figure out which >>> version >>> >>>>>>> the user is talking about. We also need to make it easy for >>> >>>>>>> the >>> users >>> >>>>>>> to describe what they are using. >>> >>>>>>> * We want to have fun :) >>> >>>>>>> >>> >>>>>>> I think the name Pelican Project will help with all goals: >>> >>>>>>> - It is clearly not the same as Sqoop. So there's no >>> >>>>>>> existing expectations on what will be supported. >>> >>>>>>> - It is a "Project" and not a product yet. >>> >>>>>>> - Sqoop and Pelican don't look or sound similar. No one can >>> >>>>>>> expect >>> to >>> >>>>>>> use Sqoop by running "pelican-shell" or to use Pelican by >>> >>>>>>> calling "sqoop import". >>> >>>>>>> - And a cute mascot will make every future presentation and >>> >>>>>>> blog >>> post >>> >>>>>>> on the topic much more fun. >>> >>>>>>> >>> >>>>>>> You do bring up good points of concern: >>> >>>>>>> >>> >>>>>>> a) Existing releases: I disagree code-names for in-progress >>> >>>>>>> development cause too much confusion. They seem fairly >>> >>>>>>> common in >>> the >>> >>>>>>> software world. >>> >>>>>>> >>> >>>>>>> >>> >>>> >>> http://royal.pingdom.com/2010/05/27/the-developer-obsession-with-cod >>> e- >>> names-114-interesting-examples/ >>> >>>>>>> >>> >>>>>>> b) "could impact the reproducibility of previous release >>> >>>>>>> builds >>> which >>> >>>>>>> is not very good for the project." >>> >>>>>>> This sounds fairly serious. Can you elaborate what you mean >>> >>>>>>> by reproducibility of release build? >>> >>>>>>> >>> >>>>>>> Gwen >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> On Fri, Jul 25, 2014 at 8:02 AM, Arvind Prabhakar < >>> arv...@apache.org> >>> >>>>>>> wrote: >>> >>>>>>>> Hi Gwen, >>> >>>>>>>> >>> >>>>>>>> Other than the recent thread [1] on our user list, is there >>> >>>>>>>> any >>> other >>> >>>>>>>> precedent regarding the confusion this issue has caused? If >>> >>>>>>>> so, I >>> >>>> would >>> >>>>>>>> appreciate if you could point it out. >>> >>>>>>>> >>> >>>>>>>> Personally, I do agree that we ought to have a better >>> >>>>>>>> mechanism to communicate the completeness (or >>> >>>>>>>> incompleteness) of a release in >>> >>>> order to >>> >>>>>>>> ensure the users understand what benefits or drawbacks they >>> >>>>>>>> may >>> get. >>> >>>>>>>> Incidentally, this was the primary reason for numbering the >>> >>>>>>>> Sqoop2 >>> >>>>>>> release >>> >>>>>>>> as 1.99.x, thereby indicating that the release is not quite >>> >>>>>>>> 2.0 >>> yet, >>> >>>>>>> which >>> >>>>>>>> seems to be not working as well as expected. >>> >>>>>>>> >>> >>>>>>>> One traditional way to alleviate this issue would be to >>> >>>>>>>> label the >>> >>>> release >>> >>>>>>>> alpha/beta etc. I prefer doing that instead of putting a >>> >>>>>>>> code >>> name for >>> >>>>>>> the >>> >>>>>>>> release for a couple of reasons - a) we have already made >>> releases of >>> >>>>>>>> Sqoop2 with the previous versioning scheme and hence >>> >>>>>>>> changing the >>> name >>> >>>>>>>> could cause more confusion; and b) renaming the branches to >>> >>>>>>>> the >>> new >>> >>>> name >>> >>>>>>>> could impact the reproducibility of previous release builds >>> >>>>>>>> which >>> is >>> >>>> not >>> >>>>>>>> very good for the project. >>> >>>>>>>> >>> >>>>>>>> Another alternative to consider would be to have very clear >>> messaging >>> >>>> in >>> >>>>>>>> the user-interface of Sqoop2 that it is still work in >>> >>>>>>>> progress >>> and not >>> >>>>>>>> considered at par with Sqoop1. >>> >>>>>>>> >>> >>>>>>>> [1] http://s.apache.org/TvD >>> >>>>>>>> >>> >>>>>>>> Regards, >>> >>>>>>>> Arvind Prabhakar >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> On Fri, Jul 25, 2014 at 7:30 AM, Venkat Ranganathan < >>> >>>>>>>> vranganat...@hortonworks.com> wrote: >>> >>>>>>>> >>> >>>>>>>>> +1 for Pelican. But documentation should not be called The >>> Pelican >>> >>>>>>> Brief >>> >>>>>>>>> :) >>> >>>>>>>>> >>> >>>>>>>>> Venkat >>> >>>>>>>>> >>> >>>>>>>>> On Thu, Jul 24, 2014 at 8:12 PM, Abraham Elmahrek < >>> a...@cloudera.com> >>> >>>>>>>>> wrote: >>> >>>>>>>>>> There's something about schlep (or schlepper) that I'm >>> >>>>>>>>>> having >>> >>>> trouble >>> >>>>>>>>>> resisting... but... +1 to Pelican. >>> >>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>>> On Thu, Jul 24, 2014 at 7:18 PM, Jarek Jarcec Cecho < >>> >>>>>>> jar...@apache.org> >>> >>>>>>>>>> wrote: >>> >>>>>>>>>> >>> >>>>>>>>>>> I’m obviously biased, but +1 to Pelican. >>> >>>>>>>>>>> >>> >>>>>>>>>>> Jarcec >>> >>>>>>>>>>> >>> >>>>>>>>>>> On Jul 24, 2014, at 7:06 PM, Martin, Nick >>> >>>>>>>>>>> <nimar...@pssd.com> >>> >>>> wrote: >>> >>>>>>>>>>> >>> >>>>>>>>>>>> +1 Pelican >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> -----Original Message----- >>> >>>>>>>>>>>> From: Gwen Shapira [mailto:gshap...@cloudera.com] >>> >>>>>>>>>>>> Sent: Thursday, July 24, 2014 9:51 PM >>> >>>>>>>>>>>> To: dev@sqoop.apache.org >>> >>>>>>>>>>>> Subject: Code name for Sqoop 2 (please vote!) >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> Hi, >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> As you may have noticed on the user list, Sqoop2 >>> >>>>>>>>>>>> confuses the >>> hell >>> >>>>>>> out >>> >>>>>>>>>>> of everyone. >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> Part of the problem is the name - Sqoop2 sounds newer >>> >>>>>>>>>>>> and >>> >>>> therefore >>> >>>>>>>>>>> better. People expect better quality and more features - >>> >>>>>>>>>>> which >>> we >>> >>>>>>> don't >>> >>>>>>>>>>> deliver :( >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> Therefore, I propose finding Sqoop2 a project code name. >>> >>>>>>>>>>>> This >>> way >>> >>>>>>> it >>> >>>>>>>>>>> will sound experimental and will not have the number "2" >>> >>>>>>>>>>> next >>> to >>> >>>> it. >>> >>>>>>>>>>>> We can use the code name to mark the branches in the >>> >>>>>>>>>>>> repo, the >>> >>>>>>>>>>> documentation, the Hue frontend, etc. This will prevent >>> confusion >>> >>>> as >>> >>>>>>> the >>> >>>>>>>>>>> name Sqoop will go back to refer to just one project, >>> >>>>>>>>>>> and one >>> that >>> >>>>>>>>> actually >>> >>>>>>>>>>> works. >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> Suggested names: >>> >>>>>>>>>>>> Project Pelican (Based on the animal on O'Reilly's >>> >>>>>>>>>>>> Sqoop >>> >>>>>>>>>>>> book) >>> >>>>>>> Project >>> >>>>>>>>>>> Schlep (Yiddish for "moving heavy package") >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> Friends, contributors, committers and PMC members - >>> >>>>>>>>>>>> please >>> respond >>> >>>>>>>>> with >>> >>>>>>>>>>> either: >>> >>>>>>>>>>>> * Vote (+1) on one of the names above >>> >>>>>>>>>>>> * Your own suggestion >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> We'll be looking to close the vote by August 1st (Next week). >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> Gwen >>> >>>>>>>>>>> >>> >>>>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> -- >>> >>>>>>>>> CONFIDENTIALITY NOTICE >>> >>>>>>>>> NOTICE: This message is intended for the use of the >>> >>>>>>>>> individual or >>> >>>>>>> entity to >>> >>>>>>>>> which it is addressed and may contain information that is >>> >>>> confidential, >>> >>>>>>>>> privileged and exempt from disclosure under applicable law. >>> >>>>>>>>> If >>> the >>> >>>>>>> reader >>> >>>>>>>>> of this message is not the intended recipient, you are >>> >>>>>>>>> hereby >>> >>>> notified >>> >>>>>>> that >>> >>>>>>>>> any printing, copying, dissemination, distribution, >>> >>>>>>>>> disclosure or forwarding of this communication is strictly >>> >>>>>>>>> prohibited. If you >>> have >>> >>>>>>>>> received this communication in error, please contact the >>> >>>>>>>>> sender >>> >>>>>>> immediately >>> >>>>>>>>> and delete it from your system. Thank You. >>> >>>>>>>>> >>> >>>>>>> >>> >>>> >>> >>>> >>> > >>> >>> -- >>> CONFIDENTIALITY NOTICE >>> NOTICE: This message is intended for the use of the individual or >>> entity to which it is addressed and may contain information that is >>> confidential, privileged and exempt from disclosure under applicable >>> law. If the reader of this message is not the intended recipient, >>> you are hereby notified that any printing, copying, dissemination, >>> distribution, disclosure or forwarding of this communication is >>> strictly prohibited. If you have received this communication in >>> error, please contact the sender immediately and delete it from your >>> system. Thank You. >>>
