Hi Reynold, thanks for the info. On Thu, Mar 17, 2016 at 2:18 PM, Reynold Xin <r...@databricks.com> wrote: > If one really feels strongly that we should go through all the overhead to > setup an ASF subproject for these modules that won't work with the new > structured streaming, and want to spearhead to setup separate repos > (preferably one subproject per connector), CI, separate JIRA, governance, > READMEs, voting, we can discuss that. Until then, I'd keep the github option > open because IMHO it is what works the best for end users (including > discoverability, issue tracking, release publishing, ...).
For those of us who are not exactly familiar with the inner workings of administrating ASF projects, would you mind explaining in more detail what this overhead is? >From my naive point of view, when I say "sub project" I assume that it's a simple as having a separate git repo for it, tied to the same parent project. Everything else - JIRA, committers, bylaws, etc - remains the same. And since the project we're talking about are very small, CI should be very simple (Travis?) and, assuming sporadic releases, things overall should not be that expensive to maintain. -- Marcelo --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org
