Tim, These are really good points.
On Wed, Jun 11, 2014 at 3:26 PM, Timothy Chen <tnac...@gmail.com> wrote: > 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 <tnac...@gmail.com> 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 <jacq...@apache.org> > 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 <tnac...@gmail.com> > 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 <jacq...@apache.org> > 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 > >>> >
