drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefán Baxter <ste...@activitystream.com>
Subject Re: drill user experience
Date Mon, 20 Jul 2015 15:45:13 GMT
Hi Ted .. and others,

I'm here and willing to help.

It's fair to add that the document, once read aft-the-fact, already
mentions some of the things that still caused me problems (?user problem?).

It's also fair to add that I'm not going anywhere :) I like this project
too much to have a few dents derail us.

But you are right, the experience has been frustrating at times.

I have spent a week trying to get to know the ins/outs of Drill and have
some thoughts to share but ultimately I have not seen anything that will
not be addressed over time. I have added several jira issues with practical
matters and mention that only because there is a common theme to those.

I think Drill is already solving specific problems for a core community but
the "in the wild" factor/polishing is still missing. This is to be expected
even though it can not be the case for long.

I look forward to using Drill and if our small startup grows then I hope we
will become meaningful contributors.

Thank you all for the outstanding work and remember that if mass adoption
is a goal then you will have to polish these nuances sooner rather than


On Mon, Jul 20, 2015 at 3:32 PM, Ted Dunning <ted.dunning@gmail.com> wrote:

> We just had Stefan over on the user@drill list stick with us through thick
> and thin to get a very simple UDF up.  He isn't a dolt by any means, but
> here is his signature on email describing his state of mind:
> Regards,
> >  -Stefan (*not the happiest camper*)
> The only reason that this guy is still with us is that Jim Bates exchanged
> quite a number of emails. The clear reason that he had problems is lack of
> documentation and thus understanding of how to write a UDF.
> The current state of affairs is that it is unnecessarily hard to contribute
> to Drill. This is clearly having a deleterious effect on building the
> community of contributors.  We need to fix this.
> There is a place on the web site that describes how to write a UDF, but it
> is clearly failing to explain the big picture of what is happening and it
> doesn't highlight the fact that you aren't really writing Java code when
> writing a Drill UDF, but instead are using Java to write in a more limited
> language.
> Stefan's recent experience should be a perfect opportunity to improve this
> documentation by describing the process better.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message