Hi all -
Here's a draft of our inaugural podling report. Per the usual guidelines,
Impala has to submit three monthly reports to the Incubator PPMC, after
which we report every quarter. The purpose of the report is to expose the
current state of the graduation effort to the Incubator, and to flag
Thanks Tom. We'll make sure to hit the deadline next month, hopefully with some
good progress to report.
Henry
Sent from my iPhone
> On Feb 10, 2016, at 8:18 AM, Tom White wrote:
>
> We were due to file a board report month, but we missed the deadline
> (see reminder below). New podlings ne
;> You received this message because you are subscribed to the Google Groups
>> "Impala Dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to impala-dev+unsubscr...@cloudera.org.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Impala Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to impala-dev+unsubscr...@cloudera.org.
>
--
Henry Robinson
Software Engineer
Cloudera
415-994-6679
tried
>copying 0.9.0 jar in thirdparty/hive*/lib and other directories like
>thirdparty/sentry*/lib, thirdparty/hbase*/lib. No luck so far.
>But I think this is also the case on x86 platform since those two
>versions of jar come from Impala source code.
>
>Could y
Hi all -
It's report season again. Here is my draft for this month's report (we
missed last month's). Do let me know what you think we should add.
I'll move to the report wiki in the next day or so.
Best,
Henry
Impala
Impala is a high-performance C++ and Java SQL query eng
See the thread from yesterday. Will copy the report to the wiki today or early
tomorrow.
Henry
> On Mar 1, 2016, at 9:24 AM, Tom White wrote:
>
> Is someone able to fill in this month's report?
>
> Thanks!
> Tom
>
>> On Thu, Feb 25, 2016 at 7:13 PM, Marvin Humphrey wrote:
>> Greetings, {p
AsterixDB
> and
> > I believe the general consensus is that this is an acceptable way to use
> > gerrit (no need to block on asf infra running a gerrit server).
> >
> > -Todd
> >
> > On Mon, Feb 29, 2016 at 2:45 PM, Henry Robinson
> wrote:
> >
> &g
0;
>>>
>>> hive.exec.max.dynamic.partitions.pernode=10;
>>>
>>> hive.exec.parallel=false
>>>
>>>
>>> I'll be really thankful if you could provide me some help here.
>>>
>>> Thanks in advance,
>>> Nishidha
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Impala Dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to impala-dev+unsubscr...@cloudera.org.
>>>
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Impala Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to impala-dev+unsubscr...@cloudera.org.
>
--
Henry Robinson
Software Engineer
Cloudera
415-994-6679
alingam,
> Technical Marketing Engineer ( Big Data Analytics)
> Mobile: 919-376-6422
>
>
--
Henry Robinson
Software Engineer
Cloudera
415-994-6679
a
> Gerrit-Branch: cdh5-trunk
> Gerrit-Owner: Matthew Jacobs
> Gerrit-Reviewer: Dan Hecht
> Gerrit-Reviewer: Henry Robinson
> Gerrit-Reviewer: Matthew Jacobs
> Gerrit-HasComments: No
>
--
Henry Robinson
Software Engineer
Cloudera
415-994-6679
One of the tasks remaining before we can push Impala's code to the ASF's
git instance is to reduce the size of the repository. Right now even a
checkout of origin/cdh5-trunk is in the multi-GB range.
The vast majority of that is in the thirdparty/ directory, which adds up
over the git history to b
k to update thirdparty/ then let's
talk about options, but otherwise let's keep things consistent.
>
> On Thu, Mar 10, 2016 at 10:04 AM Henry Robinson
> wrote:
>
>> On 10 March 2016 at 08:14, Dan Hecht (Code Review)
>> wrote:
>>
>>> Dan Hecht has
e test runtime projects, it would
> probably make things easier for the rest of the world as they could easily
> take the native-toolchain, the test environment, or both.
>
> On Thu, Mar 10, 2016 at 10:38 AM Henry Robinson wrote:
>
> > One of the tasks remaining before we can push Im
will, I think, make contributing to Impala difficult
> for
> new contributors, and I think that's more serious than the Cons for #1 and
> #3.
>
> On Thu, Mar 10, 2016 at 10:38 AM, Henry Robinson
> wrote:
>
> > One of the tasks remaining before we can push Impala's code
On 10 March 2016 at 11:24, Daniel Hecht wrote:
> On Thu, Mar 10, 2016 at 11:10 AM, Henry Robinson
> wrote:
> > I didn't think that binaries were uploaded to any repository, but instead
> > to S3 (and therefore there's no version history) or some other URL.
>
visit http://gerrit.cloudera.org:8080/2575
> > To unsubscribe, visit http://gerrit.cloudera.org:8080/settings
> >
> > Gerrit-MessageType: newchange
> > Gerrit-Change-Id: I0f6f0fea3d33872ee2c119fec824afbd7e09886e
> > Gerrit-PatchSet: 1
> > Gerrit-Project: Toolchain
> > Gerrit-Branch: master
> > Gerrit-Owner: Casey Ching
>
>
--
Henry Robinson
Software Engineer
Cloudera
415-994-6679
> Gerrit-MessageType: comment
> Gerrit-Change-Id: Ia289b285aa2ae074816d6a57e50d40df72ee2cff
> Gerrit-PatchSet: 1
> Gerrit-Project: Impala
> Gerrit-Branch: cdh5-trunk
> Gerrit-Owner: Henry Robinson
> Gerrit-Reviewer: Marcel Kornacker
> Gerrit-HasComments: No
>
--
Henry Robinson
Software Engineer
Cloudera
415-994-6679
On 16 March 2016 at 21:03, John Russell wrote:
> I'm just gathering some Apache-related URLs to include in an update for
> O'Reilly "Getting Started with Impala". On the incubator page:
>
> http://incubator.apache.org/projects/impala.html
>
> there's a link like so:
>
> Podling: http://impala.in
this issue.
>>
>> Regards,
>> valnci
>>
>> PS: llvm is built with RTTI option to 1
>> OS: rhel
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Impala Dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to impala-dev+unsubscr...@cloudera.org.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Impala Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to impala-dev+unsubscr...@cloudera.org.
>
--
Henry Robinson
Software Engineer
Cloudera
415-994-6679
Improved-McCHyp Algorithm Based Impala Query Optimization
>> [2]
>> Replication-Selection based Scheduling for Impala Parallel Query Execution
>> [3] ImpalaSim：Discrete Event Simulation Platform for Impala
>> System
>> --
>> Yan Lin
>>
ull ssh://gerrit.cloudera.org:29418/Impala refs/changes/74/2574/5
> --
> To view, visit http://gerrit.cloudera.org:8080/2574
> To unsubscribe, visit http://gerrit.cloudera.org:8080/settings
>
> Gerrit-MessageType: newpatchset
> Gerrit-Change-Id: I94e15ad67752dce21c9b7c1dced6e114905a942d
> Gerrit-PatchSet: 5
> Gerrit-Project: Impala
> Gerrit-Branch: cdh5-trunk
> Gerrit-Owner: Sailesh Mukil
> Gerrit-Reviewer: Henry Robinson
> Gerrit-Reviewer: Sailesh Mukil
>
--
Henry Robinson
Software Engineer
Cloudera
415-994-6679
es version 3.3 of
> > llvm.
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Impala Dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to impala-dev+unsubscr...@cloudera.org.
> >
>
--
Henry Robinson
Software Engineer
Cloudera
415-994-6679
Hi all -
Just wanted to draw everyone's attention to the following JIRA and its
subtasks:
https://issues.cloudera.org/browse/IMPALA-3221
These track the required steps for us to move Impala development from
Cloudera infrastructure over to the ASF. There's quite a bit of work to do
to ensure that
ks under here, because the
> same exercise of pushing initial source files and setting up a build
> process applies on the doc side as well.
>
> Thanks,
> John
>
> > On Mar 22, 2016, at 4:32 PM, Henry Robinson wrote:
> >
> > Hi all -
> >
> > Just wante
read create
>> destroy is high cost in performance！！
>>
>> what is the next plan TODO
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Impala Dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to impala-dev+unsubscr...@cloudera.org.
>>
>
>
--
Henry Robinson
Software Engineer
Cloudera
415-994-6679
Hi Zhen -
(Please use dev@impala.incubator.apache.org for your technical questions,
see https://mail-archives.apache.org/mod_mbox/incubator-impala-dev/).
Yes, the metrics have lots of locks. We thought about moving them to atomic
operations (https://issues.cloudera.org/browse/IMPALA-2397), but fo
; wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hey Pradeep,
>>>>>>>>>>>>>
>>>>>>>>>>>>> You should try running the $IMPALA_HOME/buildall.sh script in
>>>>>>>>>>>>> order to build Impala. It has a lot of necessary setup to build
>>>>>>>>>>>>> Impala.
>>>>>>>>>>>>> Here are the commands from buildall.sh that should provide the
>>>>>>>>>>>>> impala-data-source-api jar for building the FE:
>>>>>>>>>>>>>
>>>>>>>>>>>>> # build the external data source API
>>>>>>>>>>>>> pushd ${IMPALA_HOME}/ext-data-source
>>>>>>>>>>>>> ${IMPALA_HOME}/bin/mvn-quiet.sh install -DskipTests
>>>>>>>>>>>>> popd
>>>>>>>>>>>>>
>>>>>>>>>>>>> See
>>>>>>>>>>>>> https://github.com/cloudera/Impala/blob/cdh5-trunk/buildall.sh#L283
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hope that helps!
>>>>>>>>>>>>> Skye
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sat, Apr 2, 2016 at 12:55 PM, Pradeep Nayak <
>>>>>>>>>>>>> pradeep1...@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I just cloned the Impala source from github, and I am trying
>>>>>>>>>>>>>> to compile the front end per Impala wiki. I get the error below.
>>>>>>>>>>>>>> I am using
>>>>>>>>>>>>>> maven 3.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [ERROR] Failed to execute goal on project impala-frontend:
>>>>>>>>>>>>>> Could not resolve dependencies for project
>>>>>>>>>>>>>> com.cloudera.impala:impala-frontend:jar:0.1-SNAPSHOT: Failure to
>>>>>>>>>>>>>> find
>>>>>>>>>>>>>> com.cloudera.impala:impala-data-source-api:jar:1.0-SNAPSHOT in
>>>>>>>>>>>>>> https://repository.cloudera.com/content/groups/cdh-releases-rcs
>>>>>>>>>>>>>> was cached in the local repository, resolution will not be
>>>>>>>>>>>>>> reattempted
>>>>>>>>>>>>>> until the update interval of cdh.rcs.releases.repo has elapsed
>>>>>>>>>>>>>> or updates
>>>>>>>>>>>>>> are forced -> [Help 1
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is the command I used: mvn clean package
>>>>>>>>>>>>>> dependency:copy-dependencies -DskipTests=true
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Any idea getting around this problem ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Cheers!
>>>>>>>>>>>>>> Pradeep
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> You received this message because you are subscribed to the
>>>>>>>>>>>>>> Google Groups "Impala Dev" group.
>>>>>>>>>>>>>> To unsubscribe from this group and stop receiving emails from
>>>>>>>>>>>>>> it, send an email to impala-dev+unsubscr...@cloudera.org.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>> You received this message because you are subscribed to the
>>>>>>>>>>>> Google Groups "Impala Dev" group.
>>>>>>>>>>>> To unsubscribe from this group and stop receiving emails from
>>>>>>>>>>>> it, send an email to impala-dev+unsubscr...@cloudera.org.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>> --
> You received this message because you are subscribed to the Google Groups
> "Impala Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to impala-dev+unsubscr...@cloudera.org.
>
--
Henry Robinson
Software Engineer
Cloudera
415-994-6679
Hi all -
Below is my draft report for Impala for April. I'm going to copy it
straight away to the wiki (http://wiki.apache.org/incubator/April2016), so
please make changes there as you see fit.
Henry
Impala
Impala is a high-performance C++ and Java SQL query engine for data stored
in Apache Had
Just fyi, corrected a typo in the commit msg with Gerrit (didn't realise
you could do that!).
On 7 April 2016 at 22:23, Henry Robinson (Code Review)
wrote:
> Hello Alex Behm,
>
> I'd like you to reexamine a change. Please visit
>
> http://gerrit.cloudera.org:808
should hopefully not affect anyone significantly, you will just need to
> source bin/impala-config.sh to pick up the new version when you rebase. If
> you use a custom toolchain, you may need to build the new LLVM versions.
>
> Let me know if you see anything strange.
>
> - T
username is jbapple/Jim Apple. May I have edit auth?
> >
> > Thanks,
> > Jim
> >
>
--
Henry Robinson
Software Engineer
Cloudera
415-994-6679
n
total. Do you think we should remove thirdparty/ for other reasons?
On 25 May 2016 at 14:20, Michael Ho wrote:
> The long term goal is to remove thirdparty. I thought we discussed about
> it.
>
> On Wed, May 25, 2016 at 2:13 PM, Henry Robinson
> wrote:
>
>> (Sorry, not near
external
compile-time dependencies are in an easy-to-find place, which probably
makes getting an Apache release together just a little easier since we can
split the code into "developed as part of Impala" and "developed
externally".
I'm not going to stand in the way of a
in modified form.
>
> We could have a thirdparty tree under be/src/ as well.
>
>> On Wed, May 25, 2016 at 4:46 PM, Henry Robinson wrote:
>> On 25 May 2016 at 16:33, Michael Ho wrote:
>>
>> > Yes. The biggest dependency in thirdparty now is the reliance of the
LA
>
> from user 'yahoosports'
>
> --
> Bharath Vissapragada
> <http://www.cloudera.com>
>
--
Henry Robinson
Software Engineer
Cloudera
415-994-6679
(+Impala's podling mentors for advice)
On 26 May 2016 at 08:57, Jim Apple wrote:
> > I think we probably need to make a firm decision about whether we're
> going
> > to try to support non-toolchain builds. In the past we've said that it
> would
> > be nice to allow building Impala with system li
(Actually adding mentors this time)
On 26 May 2016 at 09:19, Henry Robinson wrote:
> (+Impala's podling mentors for advice)
>
>
> On 26 May 2016 at 08:57, Jim Apple wrote:
>
>> > I think we probably need to make a firm decision about whether we're
>> go
op, hbase, hive, llama and sentry.
>>>>>
>>>>> 5. Update integration jenkins job to copy the snapshots of the
>>>>> components above to
>>>>> internal jenkins repo in addition to checking them in to github.
>>>>> Update bootstrap_toolchain
>>>>> to point to internal repos.
>>>>>
>>>>> 6. Remove thirdparty directory and update integration job to not check
>>>>> in to git repo.
>>>>>
>>>>> After step (3) is done, we can already push the changes of the build
>>>>> script to ASF tree
>>>>> and check in snapshots of hadoop, hbase, llama and sentry to S3 and
>>>>> hopefully
>>>>> get the build to work.
>>>>>
>>>>
>>>> We can probably test this out as we go by manually copying the
>>>> artifacts to the impala-incubator repo. I did a test of this yesterday
>>>> (running download_requirements and copying thirdparty) and it built ok.
>>>>
>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Thanks,
>>>>> Michael
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Thanks,
>>> Michael
>>>
>>
>>
>>
>> --
>> Thanks,
>> Michael
>>
>
>
>
> --
> Todd Lipcon
> Software Engineer, Cloudera
>
--
Henry Robinson
Software Engineer
Cloudera
415-994-6679
FYI - Gerrit will be unavailable for a couple of hours on Wednesday.
-- Forwarded message --
Date: 31 May 2016 at 11:06
Subject: gerrit.cloudera.org upgrade Weds 6/1 8PM PDT
gerrit.cloudera.org will be unavailable from 8PM - 10PM PDT on 6/1/16 due
to maintenance.
We will be upg
t; I vote +1 on Impala as well.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, May 26, 2016 at 11:10 AM, Tim Armstrong <
>>>>>>>>>>> tarmstr...@cloudera.com
>>>>>>>>>>&
On 7 June 2016 at 09:56, Jim Apple wrote:
> Thank you. I think these are good questions.
>
> > What would happen if we discover that a tagged release has a critical bug
> > that was missed by the test cases? Would we have a release branch to
> > stabilise the release with any critical fixes?
>
>
s giving lot of other errors
> > related to Altivec library. Even LLVM community have no plans to provide
> > this as a hotfix before 3.9 release. So, we wanted to know how
> significant
> > is this functionality. Can we move ahead with this one issue left? What
> > features are impacted or how users will be affected due to this feature.
> >
> > Thanks,
> > Nishidha
>
>
>
--
Henry Robinson
Software Engineer
Cloudera
415-994-6679
> problem.
>
> Could you help to explain the design choice behind this? Why did Impala
> cache meta in the first place? And, is there any optimization in progress
> to make the mechanism better?
>
>
>
> Thanks.
>
>
>
>
> --
>
> Cheers,
>
> Tianyi HE
>
> (+86) 185 0042 4096
>
--
Henry Robinson
Software Engineer
Cloudera
415-994-6679
ogether and drive execution from that class. On the
> other hand keeping the QueryExecState as simple as possible for now would
> make the change less intrusive.
>
> I'd be glad for feedback on this first draft.
>
> Thanks, Lars
>
--
Henry Robinson
Software Engineer
Cloudera
415-994-6679
t;> > updating dev docs.
> >> >
> >> >> * Apache hosted Impala webpage (http://impala.incubator.apache.org/)
> >> >> * The wiki pages of the Apache Impala git repo (
> >> >> https://github.com/apache/incubator-impala)
> >> >
> >> > This isn't hosted on ASF infrastructure (unlike source code which is
> >> > mirrored), so I think we can rule this one out.
> >> >
> >> > Thanks,
> >> > Tom
> >> >
> >> >>
> >> >> Please state your preference.
> >> >>
> >> >> Dimitris
> >>
>
--
Henry Robinson
Software Engineer
Cloudera
415-994-6679
roject, so if we ever have to migrate, we'll have
> > to do it one document at a time.
> >
> > On Wed, Jul 20, 2016 at 3:25 PM, Marcel Kornacker
> wrote:
> >> How about we scope that to everything that needs revisions/comments?
> >>
> >> On Wed
Done.
On 21 July 2016 at 11:50, Dimitris Tsirogiannis
wrote:
> I don't seem to have edit access to
> https://cwiki.apache.org/confluence/display/IMPALA/Impala+Home
>
> Can someone help with that?
>
> Dimitris
>
--
Henry Robinson
Software Engineer
Cloudera
415-994-6679
Not to my knowledge.
On 21 July 2016 at 14:11, Jim Apple wrote:
> Henry, is there a way to grant all PPMC members both access to edit
> the wiki and access to administer the wiki, allowing any PPMC member
> to add new people to the wiki?
>
> On Thu, Jul 21, 2016 at 12:25 PM,
actually be shared among all fragment instances. For RPC
> > > batching (IMPALA-2550) we will transmit the descriptor table only once,
> > and
> > > it seems wasteful to re-build it for every fragment instance. This
> > probably
> > > holds true for other infor
various actions which are undertaken within
> > > the project, the corresponding approval required for that action and
> > > those who have binding votes over the action.
> > >
> > > Code Change
> > > A change made to a codebase of the project and committed by a
> > > committer. This includes source code, documentation, website content,
> > > etc.
> > >
> > > At least one +2 from a committer and no -1 from any committer.
> > >
> > > Product Release
> > > When a release of one of the project's products is ready, a vote is
> > > required to accept the release as an official release of the project.
> > >
> > > Lazy Majority of active PMC members
> > >
> > > New Branch Committer
> > > When a branch committer is proposed for the PMC
> > >
> > > Lazy consensus of active PMC members
> > >
> > > New Committer
> > > When a new committer is proposed for the project
> > >
> > > Consensus approval of active PMC members
> > >
> > > New PMC Member
> > > When a committer is proposed for the PMC
> > >
> > > Consensus approval of active PMC members
> > >
> > > Branch Committer Removal
> > > When removal of commit privileges is sought or when the branch is
> > > merged to the mainline
> > >
> > > Lazy 2/3 majority of active PMC members
> > >
> > > Committer Removal
> > > When removal of commit privileges is sought. Note: Such actions will
> > > also be referred to the ASF board by the PMC chair
> > >
> > > Lazy 2/3 majority of active PMC members (excluding the committer in
> > > question if a member of the PMC).
> > >
> > > PMC Member Removal
> > > When removal of a PMC member is sought. Note: Such actions will also
> > > be referred to the ASF board by the PMC chair.
> > >
> > > Lazy 2/3 majority of active PMC members (excluding the member in
> > question)
> > >
> > > Modifying Bylaws
> > > Modifying this document.
> > >
> > > Lazy majority of active PMC members
> > >
> > > Voting Timeframes
> > > Votes are open for a period of 72 hours to allow all active voters
> > > time to consider the vote. Votes relating to code changes are not
> > > subject to a strict timetable but should be made as timely as
> > > possible.
> >
>
--
Henry Robinson
Software Engineer
Cloudera
415-994-6679
>>
> > >> * Impala’s git repository is now hosted on ASF infrastructure
> > >>
> > >> * Impala’s website’s source is hosted on ASF’s git infrastructure and
> > >> the website is now available on https://impala.apache.org
> > >>
> > >> * Project bylaws have been ratified (
> > >> https://impala.apache.org/bylaws.html)
> > >>
> > >> * Developer documentation has started to move to the ASF-hosted wiki:
> > >> https://cwiki.apache.org/confluence/collector/pages.action?key=IMPALA
> > >>
> > >> * Work has begun in migrating to ASF-hosted JIRA
> > >>
> > >> * A patch changing the copyright headers is in review
> > >>
> >
>
--
Henry Robinson
Software Engineer
Cloudera
415-994-6679
could you add
> our report to the page?
>
> On Wed, Jul 27, 2016 at 1:37 PM, Henry Robinson
> wrote:
> > Don't feel strongly either way, but note that S3 reads and writes are
> > mediated by an HDFS-compatible connector, so it's still in some sense a
> > Ha
; >>>
> >> >>> 2. One mitigating factor to the risk of adding a new committer is
> that
> >> >>> committers rarely go overboard and start committing code that is
> >> >>> beyond their expertise.
> >> >>>
> >> >>> 3. Some projects want committers to be an expert in one area of the
> >> code.
> >> >>>
> >> >>> 4. Other people have the view that someone should be voted into a
> >> >>> committer once it saves time to make them a committer. Making
> someone
> >> >>> a committer can save time in a few ways: for instance, they can take
> >> >>> on more responsibility, taking some work off the shoulders of the
> >> >>> other committers.
> >> >>>
> >> >>> 5. Many projects will make someone a committer, or even a PMC
> member,
> >> >>> if they are not committing new features but instead are contributing
> >> >>> by filing bugs, triaging bugs, reviewing code, writing
> documentation,
> >> >>> and so on.
> >> >>>
> >> >>> My plan for this [DISCUSS] thread is that we can chat for a while if
> >> >>> anyone disagrees with any of these or wants to add something else.
> >> >>> Once the thread quiets down, I'll write the wiki page and send the
> >> >>> link to ts thread. After that, anyone with a wiki account will be
> able
> >> >>> edit the page.
> >> >>>
> >> >>> Thoughts?
> >> >>>
> >>
>
--
Henry Robinson
Software Engineer
Cloudera
415-994-6679
p://zed0.co.uk/clang-format-configurator/
>
> I would love to hear your thoughts.
>
--
Henry Robinson
Software Engineer
Cloudera
415-994-6679
ollect2: error: ld returned 1 exit status
> be/src/service/CMakeFiles/impalad.dir/build.make:166: recipe for target
> 'be/build/debug/service/impalad' failed
> make[3]: *** [be/build/debug/service/impalad] Error 1
> CMakeFiles/Makefile2:3682: recipe for target
> 'be/src/service/CMakeFiles/impalad.dir/all' failed
> make[2]: *** [be/src/service/CMakeFiles/impalad.dir/all] Error 2
> CMakeFiles/Makefile2:3694: recipe for target
> 'be/src/service/CMakeFiles/impalad.dir/rule' failed
> make[1]: *** [be/src/service/CMakeFiles/impalad.dir/rule] Error 2
>
--
Henry Robinson
Software Engineer
Cloudera
415-994-6679
Hi all -
On behalf of the Apache Impala (incubating) PMC, I'm very pleased to
announce that we've voted to invite Jim Apple as a committer to the
project, and he's accepted.
This is a big deal for two reasons. First, it's just great to have Jim
onboard - he's been driving the entire process to mo
> > > > > *`snappy::RawCompress*(char const*,
> > > > > > unsigned long, char*, unsigned long*)'
> > > > > > ...
> > > > > > boost::regex_traits >
> > > > > >::do_assign(char
> > > > > > const*, char
> > > > > >
We use boost::scoped_ptr everywhere to handle scope-owned heap-allocated
objects. C++11 has std::unique_ptr for this. I'd like to get a decision on
whether we should start standardising on unique_ptr. This is particularly
relevant for new code - should I call it out in code review?
The most signif
No, but I can't say I've audited every location. For our typical uses, I
don't see a disadvantage to unique_ptr.
>
> On Wed, Aug 31, 2016 at 10:47 AM, Henry Robinson wrote:
> > We use boost::scoped_ptr everywhere to handle scope-owned heap-allocated
> > objects. C++
g. if you have class Parent that contains a scoped_ptr child_,
> > then it's always safe for child_ to store a Parent* reference. But if you
> > change it to unique_ptr then it's no longer obvious that this is
> > safe without auditing references to child_ to make sure
> wrote:
> > For anyone wondering, I just pushed the wrong branch to gerrit, resulting
> > in a few dozen reviews being created. I'm currently working on abandoning
> > them all.
> >
> > Sorry for the spam.
> >
> > Thanks,
> > Thomas
>
--
Henry Robinson
Software Engineer
Cloudera
415-994-6679
nsfer the patch history and its gerrit
> > comments to the new "Impala-ASF" project. Some people may be iterating
> > on patches there for that reason.
> >
> > On Thu, Sep 1, 2016 at 1:04 PM, Henry Robinson
> wrote:
> >> I just removed access for
gt; Instructions are here:
>
> https://cwiki.apache.org/confluence/display/IMPALA/How+
> to+switch+to+Apache-hosted+git
>
> Pushes to this project will be disabled on October 1."
>
> 2. On October 1, you shut down all pushes to the gerrit project named
> "Impala&qu
). I feel dev@ might be more
> > > > welcoming if it only included mails sent by humans; that way, new
> > > > contributors don't have to worry about setting up filters right away.
> > > > CR emails could go to code-rev...@impala.incubator.apache.org or
> > > >
Hi all -
I want to start to get some feedback on a skunkworks project I did recently.
Impala has long had 'debug options' which are small scripts that can inject
a limited class of failures into query execution, mostly at the exec node
scope (e.g. delaying Prepare(), returning an error during Ope
> On Sep 5, 2016, at 5:01 AM, Amos Bird wrote:
>
>
> Deer impala comunity,
> I'm reading the docs of the newly runtime filtering technique,
> http://www.cloudera.com/documentation/enterprise/latest/topics/impala_runtime_filtering.html#runtime_filtering
> While being quite enlightening, this do
to a git repo and point your CI
> tool at that repo.
>
> 3. "verify[ing] that the package meets the requirements of the ASF
> policy on releases"
>
> I suppose that means http://www.apache.org/dev/release.html. I am
> asking for clarification on that from our incubating mentors.
>
> Thank you!
>
--
Henry Robinson
Software Engineer
Cloudera
415-994-6679
just told me that a moderator can send mail to
> >>> > code-review-allow-foo=b...@impala.incubator.apache.org to subscribe
> >>> > foo@bar to code-rev...@impala.incubator.apache.org]
> >>> > Moderators' addresses: jbap...@apache.org
> >>> &g
Hi -
We (at Cloudera) just posted a blog on a performance comparison between EBS
and S3 storage for Impala:
http://blog.cloudera.com/blog/2016/09/apache-impala-incubating-on-amazon-performance-and-cost-considerations-for-s3-vs-ebs/
This is a follow-on from our post on S3 support and performance
e of rule sets
produced by randomized rule generation it should be very easy to see what's
going on.
Henry
>
> Thanks,
> Juan
>
> On Fri, Sep 2, 2016 at 4:51 PM, Henry Robinson wrote:
>
> > Hi all -
> >
> > I want to start to get some feedback on a skunkw
Impala's support for Llama, which adapts Yarn for low-latency query
engines, has long since bitrotted, and never worked very well. I propose
removing it from the next version of Impala - I don't know of any
deployments relying on its use.
The initial patch is here: http://gerrit.cloudera.org:8080/
I recently added a git hook to automatically format my patches with
git-clang-format.
It happens on pre-commit. If the commit is --amend, the script chooses
HEAD~1 to compare against instead of HEAD.
The script is here:
https://gist.github.com/henryr/e89f9724eb85a6d5ea48ff0027f36793
If you want
Uhhh, scratch that - this doesn't actually commit the changes. I'll work on
a better version and post it when ready.
On 19 September 2016 at 13:36, Henry Robinson wrote:
> I recently added a git hook to automatically format my patches with
> git-clang-format.
>
> It hap
This one works a bit better for me, YMMV:
wget
https://gist.githubusercontent.com/henryr/e89f9724eb85a6d5ea48ff0027f36793/raw/2dd7888d7494cc4d38fb3f51581b503bf25b6c7c/pre-commit
-O ${IMPALA_HOME}/.git/hooks/pre-commit
On 19 September 2016 at 14:46, Henry Robinson wrote:
> Uhhh, scratch t
/topics/impala_set.html>
> seem to be only available from BE code. What should I use instead if I
> would like to have configurable behavior in the FE code? It doesn't really
> matter whether it is session-scoped or persistent or whether it is
> interactive or stored in a config
If there are three binding +1 votes
> and
> >>> >>> more binding +1 votes then binding -1 votes, the vote passes. If
> the
> >>> >>> vote passes, I will initiate a vote on this release candidate with
> the
> >>> >>> Incub
Amazing work Jim and everyone!
-- Forwarded message --
From: Jim Apple
Date: 4 October 2016 at 14:05
Subject: [RESULT] [VOTE] Impala 2.7.0 release candidate 3
To: gene...@incubator.apache.org
The vote passes with:
+1's (all binding)
Carl Steinbach
Justin Mclean
Tom White (one
x error
>
> Does this mean that IMPALA-1654 isn’t in Impala 2.7, or it’s intended to
> be but the patch hasn’t been fully merged / cherry-picked, or I’m looking
> in the wrong place to verify the 2.7 functionality?
>
> Thanks,
> John
--
Henry Robinson
Software Engineer
Cloudera
415-994-6679
Yeah, I don't think Cloudera owns the copyright to either (Mustache was
written by me, and is hosted on my private Github). Even if they did, I
don't think there's any compelling reason to grant the copyright to the
ASF. Both components would be replaceable if it was ever required.
On 6 October 20
> friendlier for new developers.
> > > >
> > > > I don't think I've seen a problem attributable to gold since it was
> > > added ~
> > > > 6 months ago. I've been using it since then and we've been using it
> for
> > >
of : the blog, the twitter account, this list, the user list,
> >>> helpwanted.apache.org, and so on.
> >>>
> >>> The tasks should be the kind of thing that someone won't need too much
> >>> hand-holding on, once their have their dev environment up and working.
> >>>
> >>> To do this, I was thinking of adding a comment to all 129 tasks to ask
> >>> the watchers of each issue if it should be labelled "newbie". This
> >>> will send hundreds of emails, which is a bummer, but it seems to me
> >>> like the best way to track the discussions and decisions.
> >>>
> >>> What does everyone think?
>
--
Henry Robinson
Software Engineer
Cloudera
415-994-6679
ternatives? Which way should I go?
>
> Thanks, Lars
>
--
Henry Robinson
Software Engineer
Cloudera
415-994-6679
t there be no label for "this is triaged and
> not suitable for newbies"?
>
> On Thu, Oct 20, 2016 at 4:14 PM, Henry Robinson
> wrote:
> > I would strongly prefer not adding "non-newbie". It seems to have limited
> > use, and is another way to increase the
e everything, and some people
> will not get their triaging work done in a timely fashion, and new
> bugs will show up and need triaging, and old bugs will (hopefully) be
> fixed by newbies, requiring us to go and find new bugs to label
> "newbie"
>
> On Thu, Oct 20, 2
ates were rejected because a pushed branch tip is behind its
> remote
> hint: counterpart. Check out this branch and integrate the remote changes
> hint: (e.g. 'git pull ...') before pushing again.
> hint: See the 'Note about fast-forwards' in 'git push --help' for details.
> ✗ ~/i2(i2521) ✗$
>
--
Henry Robinson
Software Engineer
Cloudera
415-994-6679
What do you think we should force-push?
> >
> > What did we do to cause it, and how can we avoid it in the future?
> >
> > On Mon, Oct 24, 2016 at 12:40 PM, Henry Robinson
> wrote:
> >> I also saw the same thing. The way I got around it was to try pushing to
> >
There is no publicly available distcc infrastructure, unfortunately (would
be a great thing to have, but then who's going to manage it?)
I know that Cloudera has its own distcc cluster - you might ask around
internally to see if someone can point you to that.
On 26 October 2016 at 09:57, Laszlo G
https://gerrit.cloudera.org/#/c/4880/
https://gerrit.cloudera.org/#/c/4783/ (don't be put off by the size - most
of it is test output changes).
Reviews are good practice for anyone looking to become a committer...
Henry
0. Starting immediately, the community is encouraged to submit issues
> > >>> that would break compatibility. Detailed designs are also encouraged.
> > >>>
> > >>> 1. After 2.9.0, commits that break compatibility will be allowed in
> > >>> the "master" branch.
> > >>>
> > >>> 2. After 2.9.0 a call will go out for anyone who wants to get a
> > >>> compatibility-breaking patch in that they have 3 months to do so.
> > >>>
> > >>> 3. After three months, we'll cut a new release candidate and bump all
> > >>> JIRA issues that would break compatibility to Target Version: Impala
> > >>> 4.0
> > >>>
> > >>> Thoughts?
> > >>>
> >
>
--
Henry Robinson
Software Engineer
Cloudera
415-994-6679
We have three issues open (IMPALA-{3641,3888,4342}) that all seem like the
same underlying cause - a race in metadata operations, particularly when
dropping a table.
Does anyone have a handle on what the cause might be? A lot of our test
runs - both with the ASF codebase, and our downstream CDH ve
Any committer want to sign off on this?
Thanks,
Henry
-- Forwarded message --
From: Internal Jenkins (Code Review)
Date: 4 November 2016 at 18:51
Subject: [Impala-ASF-CR] IMPALA-4048: Misc. improvements to /sessions
To: Henry Robinson , impala...@cloudera.com,
revi
How about "--enable-3.0-features" ?
On 5 November 2016 at 01:08, Marcel Kornacker wrote:
> dont-try-this-in-2dot8?
>
> On Fri, Nov 4, 2016 at 3:13 PM, Jim Apple wrote:
> > Love it. What shall we call it?
> >
> > On Thu, Nov 3, 2016 at 10:22 PM, Henry Robins
> rm -rf "${UNZIP_LOCATION}"
> echo 'PATH=/opt/dita-ot-2.3.3/bin:"${PATH}"' >> ~/.bashrc
>
> Once the docs are in, I am anticipating sending a patch to add a
> "make-docs.sh" or the like to $IMPALA_HOME/bin/. I may also add it to
> buildall.sh
>
--
Henry Robinson
Software Engineer
Cloudera
415-994-6679
e docs will be branched, too.
>
Sounds good to me, thanks for the clarifications. It's a bit unfortunate
that some commits won't get reviewed but will still go through Gerrit,
increasing the noise, but not clear what we could do differently.
>
>
> On Mon, Nov 14, 2016 at 1:43 PM,
On 5 September 2016 at 18:36, Amos Bird wrote:
>
> > Henry Robinson writes:
>
> >> Question 2,
> >>>> explain select s from yy2 where year in (select year from yy where
> year between 2000 and 2005);
> >>>> +-
On 29 November 2016 at 08:06, Jim Apple wrote:
> Should we add to our pre-merge testing (aka GVM, aka GVO) some tests
> that don't run impalad, but only build it or check for correctness?
>
> For instance:
>
> 1. bin/run_clang_tidy.sh - should we force our code to always be
> clang-tidy?
>
I don
itching to
> std::atomic?
>
--
Henry Robinson
Software Engineer
Cloudera
415-994-6679
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Impala Dev" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to impala-dev+...@cloudera.org.
>>>>>
>>>>
>>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Impala Dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to impala-dev+...@cloudera.org.
>>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Impala Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to impala-dev+unsubscr...@cloudera.org.
>
--
Henry Robinson
Software Engineer
Cloudera
415-994-6679
I'm trying to add auto[make|conf] and libtool to our toolchain. Everything
almost works, except for when the Kudu build calls autoreconf -fvi for
snappy. The error occurs when calling autoreconf calls autoconf --force.
I've discovered that removing the toolchain auto*make* from the path fixes
the i
December 2016 at 13:16, Tim Armstrong wrote:
> I had a bit of a look. It doesn't make a lot of sense to me. It seems like
> we can build snappy fine if we don't run autoreconf.
>
> On Fri, Dec 16, 2016 at 10:56 AM, Henry Robinson wrote:
>
> > I'm tr
1 - 100 of 824 matches
Mail list logo
