Over a week with no additional objections! I believe there is no need for a vote in this case, so I'll go ahead and open Jira tickets and submit patches for the changes we agreed on:
- Change the blurb on our front page to: Latest stable release is 1.4.5 (download, documentation). Latest experimental release is 1.99.3 (download, documentation) - Note that 1.99.3 is not compatible with 1.4.5 and not feature complete, it is not intended for production deployment. - Change all references to 1.99.3 to "1.99.3-prerelease" But not the artifact itself since it seems too disruptive. - Add clarifications in Sqoop2 docs that Sqoop1 parameters and connectors are not supported. Gwen On Wed, Aug 13, 2014 at 8:39 AM, Arvind Prabhakar <arv...@apache.org> wrote: > Thanks, this looks good to me. > > Regards, > Arvind Prabhakar > > > On Tue, Aug 12, 2014 at 5:05 PM, Gwen Shapira <gshap...@cloudera.com> wrote: > >> Agree. That makes sense. >> >> On Tue, Aug 12, 2014 at 4:55 PM, David Robson >> <david.rob...@software.dell.com> wrote: >> > 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. >> >>>> >>
