Sorry just to clarify more, this isn't about MapR and I think they've
done a great job already to engage with the community (ie: with folks
like me).

Just hoping to bring some awareness around Drill project itself to see
how we can improve a bit on some visibility of the project.

I know we're very early in the project so there are lots of heads down
progress going on.

Tim

On Wed, Jun 11, 2014 at 3:03 PM, Timothy Chen <[email protected]> wrote:
> Ok sounds good.
>
> I was hoping to see the larger commits like view persistence, PStore
> go through reviewboard first as lots of times there isn't even a
> design discussion and just straight code that just goes into trunk.
>
> I think to foster a better community outside of MapR, Drill should be
> more on the open about big changes and involve the community a bit
> more.
>
> Tim
>
> On Wed, Jun 11, 2014 at 2:38 PM, Jacques Nadeau <[email protected]> wrote:
>> Hey Tim,
>>
>> Great question.  I've been doing review of posted patches for a most of the
>> features before merging.  We also internally have a substantial smoke test
>> suite that we run before doing merges.  We're in the process of trying to
>> clean it up and make it available externally so that others can use this as
>> an additional check before merging.  My thought would be that minor fixes
>> that have gone through unit test + smoke test validation should be
>> mergeable directly by committers.  Larger commits should go through a
>> review process.  I haven't been perfect at this in the last little bit so
>> thanks for the reminder.
>>
>> thanks,
>> Jacques
>>
>>
>> On Wed, Jun 11, 2014 at 1:01 PM, Timothy Chen <[email protected]> wrote:
>>
>>> While I think all the changes are great, for some reason most of the
>>> commits doesn't go through any reviewboard anymore, or even have any jira
>>> too.
>>>
>>> What is our process going forward? Do all commuters just commit to trunk?
>>>
>>> Tim
>>>
>>>
>>> > On Jun 11, 2014, at 12:36 PM, Jacques Nadeau <[email protected]> wrote:
>>> >
>>> > Hey Guys,
>>> >
>>> > I've had a couple of questions about the commits that went in last night.
>>> > Some things changed in configuration that people should be aware of.
>>>  They
>>> > are as follows:
>>> >
>>> > - drill-override.conf is basically empty.  A sample drill-override is
>>> > available as well to see what some settings are that are available.  You
>>> > should move to this setup only migrate any settings that you have changed
>>> > from previous defaults.
>>> > - If you use your old settings, you'll likely to encounter a Zookeeper
>>> > exception.  This is because the drill.exec.zk.root no longer supports
>>> have
>>> > a leading slash (e.g. /drill).  To make it work, you need to either
>>> follow
>>> > the recommendation above or remove the leading slash.
>>> > - views, storage plugins and system settings are persisted across
>>> drillbit
>>> > restarts.
>>> > - view are persisted in writable workspaces (default one is dfs.tmp) as
>>> > json files called viewname.view.drill.
>>> > - Storage plugins and other drill settings are stored in a Drill PStores
>>> (a
>>> > persistent store for settings information).  In embedded mode they are
>>> > persisted to the local file system.  By default, in daemon/distributed
>>> > mode, they are stored in zookeeper.  In daemon/distributed mode, you can
>>> > also store them in HBase if you have that available as part of your
>>> cluster.
>>> > - In order to configure storage plugins, you need to use the web ui at
>>> > http://localhost:8047
>>> > - By default, Drill is initially populated with
>>> > bootstrap-storage-plugins.json in your classpath (Drill packages one in
>>> one
>>> > of the jars or you can put your own earlier in the classpath).  Once the
>>> > first node comes up and populates the storage plugin configuration, Drill
>>> > no longer uses or considers this file.
>>> >
>>> >
>>> > Let me know if there are other questions or issues that come up.  Also,
>>> be
>>> > sure to do a full clean build with this so you don't have any old/new
>>> file
>>> > conflicts.
>>> >
>>> > thanks,
>>> > Jacques
>>>

Reply via email to