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. >>>>>>> >>>
