sqoop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arvind Prabhakar <arv...@apache.org>
Subject Re: Discussing solutions to Sqoop1 and Sqoop2 confusion (was: Code name for Sqoop 2)
Date Wed, 13 Aug 2014 15:39:44 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message