Quick Q: Is there a way to make changes to the Sqoop2 docs online: http://sqoop.apache.org/docs/1.99.3/index.html
Without a new Sqoop2 release? Gwen On Tue, Aug 19, 2014 at 10:18 PM, Abraham Elmahrek <a...@cloudera.com> wrote: > +1 here as well. > > > On Tue, Aug 19, 2014 at 10:10 PM, Venkat Ranganathan < > vranganat...@hortonworks.com> wrote: > >> +1 for the proposal Gwen >> >> Venkat >> >> On Tue, Aug 19, 2014 at 7:56 PM, Jarek Jarcec Cecho <jar...@apache.org> >> wrote: >> > Go for it! >> > >> > Jarcec >> > >> > On Aug 19, 2014, at 7:50 PM, Gwen Shapira <gshap...@cloudera.com> wrote: >> > >> >> 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. >> >>>>>>>> >> >>>> >> > >> >> -- >> 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. >>
