sqoop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jarek Jarcec Cecho <jar...@apache.org>
Subject Re: Discussing solutions to Sqoop1 and Sqoop2 confusion (was: Code name for Sqoop 2)
Date Wed, 20 Aug 2014 02:56:11 GMT
Go for it!

Jarcec

On Aug 19, 2014, at 7:50 PM, Gwen Shapira <gshapira@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 <arvind@apache.org> wrote:
>> Thanks, this looks good to me.
>> 
>> Regards,
>> Arvind Prabhakar
>> 
>> 
>> On Tue, Aug 12, 2014 at 5:05 PM, Gwen Shapira <gshapira@cloudera.com> wrote:
>> 
>>> Agree. That makes sense.
>>> 
>>> On Tue, Aug 12, 2014 at 4:55 PM, David Robson
>>> <David.Robson@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:gshapira@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 <kathleen@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.Robson@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:abe@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 <
>>> vranganathan@hortonworks.com> wrote:
>>>>>> 
>>>>>>> +1 for propsal 1 also
>>>>>>> 
>>>>>>> Thanks
>>>>>>> 
>>>>>>> Venkat
>>>>>>> 
>>>>>>> On Fri, Aug 1, 2014 at 9:38 AM, Jarek Jarcec Cecho
>>>>>>> <jarcec@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 <gshapira@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
>>>>>>>>> <arvind@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
>>>>>>>>>> <jarcec@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
>>>>>>>>>>> <gshapira@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
>>>>>>>>>>>> <arvind@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 <
>>>>>>> gshapira@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+FPaw7VHw1Q@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 <
>>>>>>> arvind@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 <
>>>>>>>>>>>>>>> vranganathan@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 <
>>>>>>> abe@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 <
>>>>>>>>>>>>>> jarcec@apache.org>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> I’m obviously biased,
but +1 to Pelican.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Jarcec
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On Jul 24, 2014,
at 7:06 PM, Martin, Nick
>>>>>>>>>>>>>>>>>> <NiMartin@pssd.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> +1 Pelican
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> -----Original
Message-----
>>>>>>>>>>>>>>>>>>> From: Gwen Shapira
[mailto:gshapira@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.
>>>>>>> 
>>> 


Mime
View raw message