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 >>
