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 >
