On Tue, Jan 12, 2016 at 9:21 AM, Jason Altekruse <[email protected]> wrote: > Wes, > > I think the overall consensus is that one repo makes the most sense. > Considering the headache of just managing the gh-pages branch in a project > (I normally just have a separate copy of the repo for this) I would not > advocate for Julian's suggestion of diverging histories in the one repo. He > seemed to just be mentioning for completeness in the discussion anyway, but > no one else had commented on it. > > Also considering the nature of the project is a cross-tool in-memory format, > I assume we will want at least some testing that goes between the different > implementations running in the same process or with shared memory between > two or more processes. This will be easiest if we can run both (all, if we > also have python and other languages) builds followed by some kind of > integration test script/framework.
1 repo is good; as soon as (if) we have the project approval and Apache git repo set up, I can propose patches there. > > As far as the existing work is concerned, I'm not sure everyone is aware of > the C++ code inside of Drill that can represent at least the scalar types in > Drill's existing Value Vectors [1]. This is currently used by the native > client written to hook up an ODBC driver. > I have read this code. From my perspective, it would be less work to collaborate on a self-contained implementation that closely models the Arrow / VV spec that includes builder classes and its own memory management without coupling to Drill details. I started prototyping something here (warning: only a few actual days of coding here): https://github.com/arrow-data/arrow-cpp/tree/master/src/arrow For example, you can see an example constructing an Array<Int32> or String (== Array<UInt8>) column in the tests here https://github.com/arrow-data/arrow-cpp/blob/master/src/arrow/builder-test.cc#L328 I've been planning to use this as the basis of a C++ Parquet reader-writer and the associated Python pandas-like layer which includes in-memory analytics on Arrow data structures. > Parth who is included here has been the primary owner of this C++ code > throughout it's life in Drill. Parth, what do you think is the best strategy > for managing the C++ code right now? As the C++ build is not tied into the > Java one, as I understand it we just run it manually when updates are made > there and we need to update ODBC. Would it be disruptive to move the code to > the arrow repo? If so, we could include Drill as a submodule in the new > repo, or put Wes's work so far in the Drill repo. If we can enumerate the non-Drill-client related parts (i.e. the array accessors and data structures-oriented code) that would make sense in a standalone Arrow library it would be great to start a side discussion about the design of the C++ reference implementation (metadata / schemas, IPC, array builders and accessors, etc.). Since this is a quite urgent for me (intending to deliver a minimally viable pandas-like Arrow + Parquet in Python stack in the next ~3 months) it would be great to do this sooner rather than later. cheers, Wes > > [1] - https://github.com/apache/drill/tree/master/contrib/native/client > > - Jason > > > > On Wed, Dec 30, 2015 at 12:19 PM, Jacques Nadeau <[email protected]> wrote: >> >> Sounds good. We'll need to start the Apache repo with just Apache code >> given how we've done the proposal. After we get established, we can break >> any independent progress you've made into a set of patches to add to the >> existing repo through the normal Apache commit process. >> >> >> >> >> >> -- >> Jacques Nadeau >> CTO and Co-Founder, Dremio >> >> On Wed, Dec 30, 2015 at 12:03 PM, Wes McKinney <[email protected]> wrote: >>> >>> Great to hear on the name approval! >>> >>> If it is OK I will consolidate to 1 repo and nest the C++ code under >>> cpp/ and add some format Markdown files there in the next week or so. >>> >>> One repo is perfectly fine (as compared with Parquet) as long as the >>> language implementations can evolve and be released in a >>> non-monolithic way. >>> >>> On Wed, Dec 30, 2015 at 11:19 AM, Jacques Nadeau <[email protected]> >>> wrote: >>> > Good news guys, Apache trademarks just approved the name Apache Arrow >>> > [1]. I >>> > will update the proposal and resubmit to the board. >>> > >>> > thanks, >>> > Jacques >>> > >>> > [1] https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-92 >>> > >>> > -- >>> > Jacques Nadeau >>> > CTO and Co-Founder, Dremio >>> > >>> > On Thu, Dec 17, 2015 at 11:21 AM, Julian Hyde <[email protected]> wrote: >>> >> >>> >> You can also do the trick of having two branches that diverge at the >>> >> very >>> >> first commit. C++ and Java are in the same repository but if you have >>> >> a >>> >> given branch checked out you are looking at one or the other. >>> >> >>> >> That said, I’d be inclined to put everything in the same repo. >>> >> >>> >> The repo size will not be prohibitive as long as we follow Julien’s >>> >> recommendation to put large objects (e.g. test data sets) elsewhere. >>> >> >>> >> And it makes it possible for a single patch to update both C++ and >>> >> Java >>> >> code lines, and also update shared content (the specification and the >>> >> source >>> >> files for the web site). >>> >> >>> >> And having said THAT, it doesn’t really matter. If we realize we’ve >>> >> made a >>> >> horrible mistake in 2 years we can split the repo or merge the repos. >>> >> >>> >> Julian >>> >> >>> >> >>> >> > On Dec 17, 2015, at 11:09 AM, Julien Le Dem <[email protected]> >>> >> > wrote: >>> >> > >>> >> > I guess what I meant is: separate repos => separate releases. >>> >> > One repo can still have separate releases as was mentioned. >>> >> > >>> >> > I’m not too fond of the separate repos in parquet anymore. >>> >> > The only reason I would split to a separate repo now is if we have >>> >> > large >>> >> > files for regression testing and that’s because of how git works. >>> >> > >>> >> > Separate directories java and cpp seems a given since they will >>> >> > build >>> >> > independently. >>> >> > >>> >> > I’d vote for just one repo with /format /java /cpp. >>> >> > both /java and /cpp depend on /format >>> >> > >>> >> > releasing the format independently is useful because the semantics >>> >> > are >>> >> > different than for an API. >>> >> > A breaking change in the format may not be an API change and >>> >> > vice-versa. >>> >> > >>> >> > Julien >>> >> > >>> >> > >>> >> >> On Dec 16, 2015, at 7:03 PM, Ted Dunning <[email protected]> >>> >> >> wrote: >>> >> >> >>> >> >> >>> >> >> One repo should be a given. >>> >> >> >>> >> >> Separate directories should be the question. >>> >> >> >>> >> >> >>> >> >> >>> >> >> On Wed, Dec 16, 2015 at 6:21 PM, Jason Altekruse >>> >> >> <[email protected] <mailto:[email protected]>> wrote: >>> >> >> I think that is a worthwhile discussion, parallel vs independent >>> >> >> releases, but I don't understand why it relates to one repo or not. >>> >> >> Couldn't >>> >> >> the release tag names just include the language (cpp, java python)? >>> >> >> What >>> >> >> other parts of version control are related to releasing? >>> >> >> >>> >> >> On Wed, Dec 16, 2015 at 5:57 PM, Julien Le Dem <[email protected] >>> >> >> <mailto:[email protected]>> wrote: >>> >> >> for the git repos it boils down to wether we want to release >>> >> >> arrow-cpp >>> >> >> and arrow-java independently or together with the same version >>> >> >> numbers. >>> >> >> >>> >> >> >>> >> >> >>> >> >> On Tue, Dec 15, 2015 at 7:15 PM, Jacques Nadeau <[email protected] >>> >> >> <mailto:[email protected]>> wrote: >>> >> >> Thanks Wes, that's great! >>> >> >> On Dec 14, 2015 9:44 AM, "Wes McKinney" <[email protected] >>> >> >> <mailto:[email protected]>> wrote: >>> >> >> >>> >> >>> hi folks, >>> >> >>> >>> >> >>> In the interim I created a new public GitHub organization to host >>> >> >>> code >>> >> >>> for this effort so we can organize ourselves in advance of more >>> >> >>> progress in the ASF: >>> >> >>> >>> >> >>> https://github.com/arrow-data <https://github.com/arrow-data> >>> >> >>> >>> >> >>> I have a partial C++ implementation of the Arrow spec that I can >>> >> >>> move >>> >> >>> there, along with a to-be-Markdown-ified version of a >>> >> >>> specification >>> >> >>> subject to more iteration. The more pressing short term matter >>> >> >>> will be >>> >> >>> making some progress on the metadata / data headers / IPC protocol >>> >> >>> (e.g. using Flatbuffers or the like). >>> >> >>> >>> >> >>> Thoughts on git repo structure? >>> >> >>> >>> >> >>> 1) Avro-style — "one repo to rule them all" >>> >> >>> 2) Parquet-style — arrow-format, arrow-cpp, arrow-java, etc. >>> >> >>> >>> >> >>> (I'm personally more in the latter camp, though integration tests >>> >> >>> may >>> >> >>> be more tedious that way) >>> >> >>> >>> >> >>> Thanks >>> >> >>> >>> >> >>> On Thu, Dec 3, 2015 at 4:18 PM, Jacques Nadeau <[email protected] >>> >> >>> <mailto:[email protected]>> wrote: >>> >> >>>> I've opened a name search for our top vote getter. >>> >> >>>> >>> >> >>>> https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-92 >>> >> >>>> <https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-92> >>> >> >>>> >>> >> >>>> >>> >> >>>> I also just realized that my previously email dropped other >>> >> >>>> recipients. >>> >> >>>> Here it is below. >>> >> >>>> >>> >> >>>> ---- >>> >> >>>> I think we can call the voting closed. Top vote getters: >>> >> >>>> >>> >> >>>> Apache Arrow (17) >>> >> >>>> Apache Herringbone (9) >>> >> >>>> Apache Joist (8) >>> >> >>>> Apache Colbuf (8) >>> >> >>>> >>> >> >>>> I'll up a PODLINGNAMESEARCH-* shortly for Arrow. >>> >> >>>> >>> >> >>>> --- >>> >> >>>> >>> >> >>>> >>> >> >>>> >>> >> >>>> >>> >> >>>> >>> >> >>>> >>> >> >>>> -- >>> >> >>>> Jacques Nadeau >>> >> >>>> CTO and Co-Founder, Dremio >>> >> >>>> >>> >> >>>> On Thu, Dec 3, 2015 at 1:23 AM, Marcel Kornacker >>> >> >>>> <[email protected] >>> >> >>>> <mailto:[email protected]>> >>> >> >>>> wrote: >>> >> >>>>> >>> >> >>>>> Just added my vote. >>> >> >>>>> >>> >> >>>>> On Thu, Dec 3, 2015 at 12:51 PM, Wes McKinney <[email protected] >>> >> >>>>> <mailto:[email protected]>> wrote: >>> >> >>>>>> Shall we call the voting closed? Any last stragglers? >>> >> >>>>>> >>> >> >>>>>> On Tue, Dec 1, 2015 at 5:39 PM, Ted Dunning >>> >> >>>>>> <[email protected] >>> >> >>>>>> <mailto:[email protected]>> >>> >> >>>>>> wrote: >>> >> >>>>>>> >>> >> >>>>>>> Apache can handle this if we set the groundwork in place. >>> >> >>>>>>> >>> >> >>>>>>> Also, Twitter's lawyers work for Twitter, not for Apache. As >>> >> >>>>>>> such, >>> >> >>>>>>> their >>> >> >>>>>>> opinions can't be taken by Apache as legal advice. There are >>> >> >>>>>>> issues >>> >> >>> of >>> >> >>>>>>> privilege, conflict of interest and so on. >>> >> >>>>>>> >>> >> >>>>>>> >>> >> >>>>>>> >>> >> >>>>>>> On Wed, Dec 2, 2015 at 7:51 AM, Alex Levenson >>> >> >>>>>>> <[email protected] <mailto:[email protected]>> >>> >> >>>>>>> wrote: >>> >> >>>>>>>> >>> >> >>>>>>>> I can ask about whether Twitter's lawyers can help out -- is >>> >> >>>>>>>> that >>> >> >>>>>>>> something we need? Or is that something apache helps out with >>> >> >>>>>>>> in >>> >> >>>>>>>> the >>> >> >>>>>>>> next >>> >> >>>>>>>> step? >>> >> >>>>>>>> >>> >> >>>>>>>> On Mon, Nov 30, 2015 at 9:32 PM, Julian Hyde >>> >> >>>>>>>> <[email protected] >>> >> >>>>>>>> <mailto:[email protected]>> >>> >> >>> wrote: >>> >> >>>>>>>>> >>> >> >>>>>>>>> +1 to have a vote tomorrow. >>> >> >>>>>>>>> >>> >> >>>>>>>>> Assuming that Vector is out of play, I just did a quick >>> >> >>>>>>>>> search >>> >> >>>>>>>>> for >>> >> >>>>>>>>> the >>> >> >>>>>>>>> top 4 remaining, (“arrow”, “honeycomb”, “herringbone”, >>> >> >>>>>>>>> “joist"), >>> >> >>>>>>>>> at >>> >> >>>>>>>>> sourceforge, open hub, trademarkia, and on google. There are >>> >> >>>>>>>>> no >>> >> >>>>>>>>> trademarks >>> >> >>>>>>>>> for these in similar subject areas. There is a moderately >>> >> >>>>>>>>> active >>> >> >>>>>>>>> project >>> >> >>>>>>>>> called “joist” [1]. >>> >> >>>>>>>>> >>> >> >>>>>>>>> I will point out that “Apache Arrow” has native-american >>> >> >>> connotations >>> >> >>>>>>>>> that we may or may not want to live with (just ask the >>> >> >>>>>>>>> Washington >>> >> >>>>>>>>> Redskins >>> >> >>>>>>>>> how they feel about their name). >>> >> >>>>>>>>> >>> >> >>>>>>>>> If someone would like to vet other names, use the links on >>> >> >>>>>>>>> https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-90 >>> >> >>>>>>>>> >>> >> >>>>>>>>> <https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-90>, >>> >> >>>>>>>>> and >>> >> >>> fill >>> >> >>>>>>>>> out >>> >> >>>>>>>>> column C in the spreadsheet. >>> >> >>>>>>>>> >>> >> >>>>>>>>> Julian >>> >> >>>>>>>>> >>> >> >>>>>>>>> [1] https://github.com/stephenh/joist >>> >> >>>>>>>>> <https://github.com/stephenh/joist> >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>>>>>>>> On Nov 30, 2015, at 7:01 PM, Jacques Nadeau >>> >> >>>>>>>>> <[email protected] >>> >> >>>>>>>>> <mailto:[email protected]>> >>> >> >>>>>>>>> wrote: >>> >> >>>>>>>>> >>> >> >>>>>>>>> +1 >>> >> >>>>>>>>> >>> >> >>>>>>>>> -- >>> >> >>>>>>>>> Jacques Nadeau >>> >> >>>>>>>>> CTO and Co-Founder, Dremio >>> >> >>>>>>>>> >>> >> >>>>>>>>> On Mon, Nov 30, 2015 at 6:34 PM, Wes McKinney >>> >> >>>>>>>>> <[email protected] >>> >> >>>>>>>>> <mailto:[email protected]>> >>> >> >>>>>>>>> wrote: >>> >> >>>>>>>>> >>> >> >>>>>>>>> Should we have a last call for votes, closing EOD tomorrow >>> >> >>> (Tuesday)? >>> >> >>>>>>>>> I >>> >> >>>>>>>>> missed this for a few days last week with holiday travel. >>> >> >>>>>>>>> >>> >> >>>>>>>>> On Thu, Nov 26, 2015 at 3:04 PM, Julian Hyde < >>> >> >>> [email protected] <mailto:[email protected]>> >>> >> >>>>>>>>> wrote: >>> >> >>>>>>>>> >>> >> >>>>>>>>> Consulting a lawyer is part of the Apache branding process >>> >> >>>>>>>>> but >>> >> >>>>>>>>> the >>> >> >>>>>>>>> first >>> >> >>>>>>>>> stage is to gather a list of potential conflicts - >>> >> >>>>>>>>> https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-90 >>> >> >>>>>>>>> <https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-90> >>> >> >>>>>>>>> is an >>> >> >>>>>>>>> example. >>> >> >>>>>>>>> >>> >> >>>>>>>>> The other part, frankly, is to pick your battles. >>> >> >>>>>>>>> >>> >> >>>>>>>>> A year or so ago Actian re-branded Vectorwise as Vector. >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>> >>> >> >>> >>> >> >>> http://www.zdnet.com/article/actian-consolidates-its-analytics-portfolio/ >>> >> >>> >>> >> >>> <http://www.zdnet.com/article/actian-consolidates-its-analytics-portfolio/>. >>> >> >>>>>>>>> Given that it is an analytic database in the Hadoop space I >>> >> >>>>>>>>> think >>> >> >>>>>>>>> that is >>> >> >>>>>>>>> as close to a “direct hit” as it gets. I don’t think we need >>> >> >>>>>>>>> a >>> >> >>> lawyer >>> >> >>>>>>>>> to >>> >> >>>>>>>>> tell us that. Certainly it makes sense to look for conflicts >>> >> >>>>>>>>> for >>> >> >>> the >>> >> >>>>>>>>> other >>> >> >>>>>>>>> alternatives before consulting lawyers. >>> >> >>>>>>>>> >>> >> >>>>>>>>> Julian >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>>>>>>>> On Nov 25, 2015, at 9:42 PM, Marcel Kornacker >>> >> >>>>>>>>> <[email protected] <mailto:[email protected]> >>> >> >>>> >>> >> >>>>>>>>> wrote: >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>>>>>>>> On Tue, Nov 24, 2015 at 3:25 PM, Jacques Nadeau < >>> >> >>> [email protected] <mailto:[email protected]>> >>> >> >>>>>>>>> wrote: >>> >> >>>>>>>>> >>> >> >>>>>>>>> Ok guys, >>> >> >>>>>>>>> >>> >> >>>>>>>>> I don't think anyone is doing a thorough analysis of >>> >> >>>>>>>>> viaability. >>> >> >>>>>>>>> I >>> >> >>>>>>>>> did a >>> >> >>>>>>>>> quick glance and the top one (Vector) seems like it would >>> >> >>>>>>>>> have >>> >> >>>>>>>>> an >>> >> >>>>>>>>> issue >>> >> >>>>>>>>> with conflict of an Actian product. The may be fine. Let's >>> >> >>>>>>>>> do a >>> >> >>>>>>>>> second >>> >> >>>>>>>>> phase vote. >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>>>>>>>> I'm assuming you mean Vectorwise? >>> >> >>>>>>>>> >>> >> >>>>>>>>> Before we do anything else, could we have a lawyer look into >>> >> >>>>>>>>> this? >>> >> >>>>>>>>> Last >>> >> >>>>>>>>> time around that I remember (Parquet), Twitter's lawyers did >>> >> >>>>>>>>> a >>> >> >>>>>>>>> good >>> >> >>>>>>>>> job >>> >> >>>>>>>>> of >>> >> >>>>>>>>> weeding out the potential trademark violations. >>> >> >>>>>>>>> >>> >> >>>>>>>>> Alex, could Twitter get involved this time around as well? >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>>>>>>>> Pick your top 3 (1,2,3 with 3 being top preference) >>> >> >>>>>>>>> >>> >> >>>>>>>>> Let's get this done by Friday and then we can do a podling >>> >> >>>>>>>>> name >>> >> >>>>>>>>> search >>> >> >>>>>>>>> starting with the top one. >>> >> >>>>>>>>> >>> >> >>>>>>>>> Link again: >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>> >>> >> >>> >>> >> >>> https://docs.google.com/spreadsheets/d/1q6UqluW6SLuMKRwW2TBGBzHfYLlXYm37eKJlIxWQGQM/edit#gid=304381532&vpid=A1 >>> >> >>> >>> >> >>> <https://docs.google.com/spreadsheets/d/1q6UqluW6SLuMKRwW2TBGBzHfYLlXYm37eKJlIxWQGQM/edit#gid=304381532&vpid=A1> >>> >> >>>>>>>>> >>> >> >>>>>>>>> thanks >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>>>>>>>> -- >>> >> >>>>>>>>> Jacques Nadeau >>> >> >>>>>>>>> CTO and Co-Founder, Dremio >>> >> >>>>>>>>> >>> >> >>>>>>>>> On Fri, Nov 20, 2015 at 9:24 AM, Jacques Nadeau < >>> >> >>> [email protected] <mailto:[email protected]>> >>> >> >>>>>>>>> wrote: >>> >> >>>>>>>>> >>> >> >>>>>>>>> Ok, it looks like we have a candidate list (we actually got >>> >> >>>>>>>>> 11 >>> >> >>> since >>> >> >>>>>>>>> there was a three-way tie for ninth place): >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>>>>>>>> VectorArrowhoneycombHerringbonejoistV2Pietcolbufbatonimpulsevictor >>> >> >>>>>>>>> Next we need to do trademark searches on each of these to >>> >> >>>>>>>>> see >>> >> >>> whether >>> >> >>>>>>>>> we're likely to have success. I've moved candidates to a >>> >> >>>>>>>>> second >>> >> >>> tab: >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>> >>> >> >>> >>> >> >>> https://docs.google.com/spreadsheets/d/1q6UqluW6SLuMKRwW2TBGBzHfYLlXYm37eKJlIxWQGQM/edit#gid=304381532 >>> >> >>> >>> >> >>> <https://docs.google.com/spreadsheets/d/1q6UqluW6SLuMKRwW2TBGBzHfYLlXYm37eKJlIxWQGQM/edit#gid=304381532> >>> >> >>>>>>>>> >>> >> >>>>>>>>> Anybody want to give a hand in analyzing potential >>> >> >>>>>>>>> conflicts? >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>>>>>>>> -- >>> >> >>>>>>>>> Jacques Nadeau >>> >> >>>>>>>>> CTO and Co-Founder, Dremio >>> >> >>>>>>>>> >>> >> >>>>>>>>> On Mon, Nov 16, 2015 at 12:10 PM, Jacques Nadeau < >>> >> >>> [email protected] <mailto:[email protected]>> >>> >> >>>>>>>>> wrote: >>> >> >>>>>>>>> >>> >> >>>>>>>>> Everybody should pick their ten favorites using the numbers >>> >> >>>>>>>>> 1 to >>> >> >>> 10. >>> >> >>>>>>>>> >>> >> >>>>>>>>> 10 is most preferred >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>>>>>>>> -- >>> >> >>>>>>>>> Jacques Nadeau >>> >> >>>>>>>>> CTO and Co-Founder, Dremio >>> >> >>>>>>>>> >>> >> >>>>>>>>> On Mon, Nov 16, 2015 at 10:17 AM, Ted Dunning < >>> >> >>> [email protected] <mailto:[email protected]>> >>> >> >>>>>>>>> wrote: >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>>>>>>>> Single vote for most preferred? >>> >> >>>>>>>>> >>> >> >>>>>>>>> Single transferable vote? >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>>>>>>>> On Tue, Nov 17, 2015 at 2:50 AM, Jacques Nadeau < >>> >> >>> [email protected] <mailto:[email protected]>> >>> >> >>>>>>>>> wrote: >>> >> >>>>>>>>> >>> >> >>>>>>>>> Given that a bunch of people added names to the sheet, I'll >>> >> >>>>>>>>> take >>> >> >>>>>>>>> that as tacit agreement to the proposed process. >>> >> >>>>>>>>> >>> >> >>>>>>>>> Let's move to the first vote phase. I've added a column for >>> >> >>>>>>>>> everybody's votes. Let's try to wrap up the vote by 10am on >>> >> >>>>>>>>> Wednesday. >>> >> >>>>>>>>> >>> >> >>>>>>>>> thanks! >>> >> >>>>>>>>> Jacques >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>>>>>>>> -- >>> >> >>>>>>>>> Jacques Nadeau >>> >> >>>>>>>>> CTO and Co-Founder, Dremio >>> >> >>>>>>>>> >>> >> >>>>>>>>> On Thu, Nov 12, 2015 at 12:03 PM, Jacques Nadeau < >>> >> >>> [email protected] <mailto:[email protected]> >>> >> >>>>>>>>> >>> >> >>>>>>>>> wrote: >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>>>>>>>> Hey Guys, >>> >> >>>>>>>>> >>> >> >>>>>>>>> It sounds like we need to do a little more work on the >>> >> >>>>>>>>> Vector >>> >> >>>>>>>>> proposal >>> >> >>>>>>>>> before the board would like to consider it. The main point >>> >> >>>>>>>>> of >>> >> >>>>>>>>> contention >>> >> >>>>>>>>> right now is the name of the project. We need to decide on a >>> >> >>>>>>>>> name >>> >> >>>>>>>>> and get >>> >> >>>>>>>>> it signed off through PODLINGNAMESEARCH. >>> >> >>>>>>>>> >>> >> >>>>>>>>> Naming is extremely subjective so I'd like to propose a >>> >> >>>>>>>>> process >>> >> >>>>>>>>> for >>> >> >>>>>>>>> selection that minimizes pain. This is an initial proposal >>> >> >>>>>>>>> and >>> >> >>>>>>>>> >>> >> >>>>>>>>> We do the naming in the following steps >>> >> >>>>>>>>> - 1: Collect a set of names to be considered >>> >> >>>>>>>>> - 2: Run a vote for 2 days where each member ranks their top >>> >> >>>>>>>>> 10 >>> >> >>>>>>>>> options >>> >> >>>>>>>>> 1..10 >>> >> >>>>>>>>> - 3: Take the top ten vote getters and do a basic analysis >>> >> >>>>>>>>> of >>> >> >>>>>>>>> whether we >>> >> >>>>>>>>> think that any have legal issues. Keep dropping names that >>> >> >>>>>>>>> have >>> >> >>>>>>>>> this until >>> >> >>>>>>>>> we get with 10 reasonably solid candidate names >>> >> >>>>>>>>> - 5: Take the top ten names and give people 48 hours to rank >>> >> >>>>>>>>> their >>> >> >>>>>>>>> top 3 >>> >> >>>>>>>>> names >>> >> >>>>>>>>> - 6: Start a PODLINGNAMESEARCH on the top rank one, if that >>> >> >>>>>>>>> doesn't >>> >> >>>>>>>>> work, >>> >> >>>>>>>>> try the second and third options. >>> >> >>>>>>>>> >>> >> >>>>>>>>> I suggest we take name suggestions for step 1 from everyone >>> >> >>>>>>>>> but >>> >> >>> then >>> >> >>>>>>>>> constrain the voting to the newly proposed project [1]. We >>> >> >>>>>>>>> could >>> >> >>>>>>>>> just do >>> >> >>>>>>>>> this in a private email thread but I think doing it on Drill >>> >> >>>>>>>>> dev >>> >> >>>>>>>>> is >>> >> >>>>>>>>> better >>> >> >>>>>>>>> in the interest of transparency. This isn't the perfect >>> >> >>>>>>>>> place >>> >> >>>>>>>>> for >>> >> >>>>>>>>> that but >>> >> >>>>>>>>> I'm not sure a better place exists. >>> >> >>>>>>>>> >>> >> >>>>>>>>> I'm up for changing any or all of this depending on what >>> >> >>>>>>>>> others >>> >> >>>>>>>>> think. Just >>> >> >>>>>>>>> wanted to get the ball rolling on a proposed process. >>> >> >>>>>>>>> >>> >> >>>>>>>>> If this works, I've posted a doc at [2] that we can use for >>> >> >>>>>>>>> step >>> >> >>>>>>>>> 1. >>> >> >>>>>>>>> >>> >> >>>>>>>>> Thanks, >>> >> >>>>>>>>> Jacques >>> >> >>>>>>>>> >>> >> >>>>>>>>> [1] List of proposed new project members/voters: Todd >>> >> >>>>>>>>> Lipcon, >>> >> >>>>>>>>> Ted >>> >> >>>>>>>>> Dunning, >>> >> >>>>>>>>> Michael Stack, P. Taylor Goetz, Julian Hyde, Julien Le Dem, >>> >> >>>>>>>>> Jacques >>> >> >>>>>>>>> Nadeau, >>> >> >>>>>>>>> James Taylor, Jake Luciani, Parth Chandra, Alex Levenson, >>> >> >>>>>>>>> Marcel >>> >> >>>>>>>>> Kornacker, >>> >> >>>>>>>>> Steven Phillips, Hanifi Gunes, Wes McKinney, Jason >>> >> >>>>>>>>> Altekruse, >>> >> >>>>>>>>> David >>> >> >>>>>>>>> Alves, >>> >> >>>>>>>>> Zain Asgar, Ippokratis Pandis, Abdel Hakim Deneche, Reynold >>> >> >>>>>>>>> Xin. >>> >> >>>>>>>>> [2] >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>> >>> >> >>> >>> >> >>> https://docs.google.com/spreadsheets/d/1q6UqluW6SLuMKRwW2TBGBzHfYLlXYm37eKJlIxWQGQM/edit#gid=0 >>> >> >>> >>> >> >>> <https://docs.google.com/spreadsheets/d/1q6UqluW6SLuMKRwW2TBGBzHfYLlXYm37eKJlIxWQGQM/edit#gid=0> >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>>>>>>> >>> >> >>>>>>>> >>> >> >>>>>>>> >>> >> >>>>>>>> -- >>> >> >>>>>>>> Alex Levenson >>> >> >>>>>>>> @THISWILLWORK >>> >> >>>>>>> >>> >> >>>>>>> >>> >> >>>> >>> >> >>>> >>> >> >>> >>> >> >> >>> >> >> >>> >> >> >>> >> >> -- >>> >> >> Julien >>> >> >> >>> >> >> >>> >> > >>> >> >>> > >> >> >
