If the intention is to actually decouple and give a life of it's own to these connectors, I would have expected that they would still be hosted as different git repositories inside Apache even tough users will not really see much difference as they would still be mirrored in GitHub. This makes it much easier on the legal departments of the upstream consumers and customers as well because the code still follow the so well received and trusted Apache Governance and Apache Release Policies. As for implementation details, we can have multiple repositories if we see a lot of fragmented releases, or a single "connectors" repository which in our side would make administration more easily.
On Thu, Mar 17, 2016 at 2:33 PM, Marcelo Vanzin <van...@cloudera.com> wrote: > 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, ...). > Agree that there might be a little overhead, but there are ways to minimize this, and I am sure there are volunteers willing to help in favor of having a more unifying project. Breaking things into multiple projects, and having to manage the matrix of supported versions will be hell worst overhead. > > 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. > > Subprojects or even if we send this back to incubator as "connectors project" is better then public github per package in my opinion. Now, if with this move is signalizing to customers that the Streaming API as in 1.x is going away in favor the new structure streaming APIs , then I guess this is a complete different discussion. -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/
