Benedict, Your concerns are valid and its great to think through issues that might occur in the future. I personally have never thought that the driver should be treated as a separate entity because as a user, Cassandra cannot be used _without_ a driver. Drivers are the public interface and are tightly coupled with the server. I personally feel that we should take the donation as part of the Cassandra project and if we see issues we try to resolve them at that point.
Thanks, Dinesh > On Apr 23, 2020, at 3:54 PM, Benedict Elliott Smith <bened...@apache.org> > wrote: > > Do you have some examples of issues? > > So, to explain my thinking: I believe there is value in most contributors > being able to know and understand a majority of what the project undertakes. > Many people track a wide variety of activity on the project, and whether they > express an opinion they probably form one and will involve themselves if they > consider it important to do so. I worry that importing several distinct and > only loosely related projects to the same governance and communication > structures has a strong potential to undermine that capability, as people > begin to assume that activity and decision-making is unrelated to them - and > if that happens I think something important is lost. > > The sidecar challenges this already but seems hopefully manageable: it is a > logical extension of Cassandra, existing primarily to plug gaps in > Cassandra's own functionality, and features may migrate to Cassandra over > time. It is likely to have releases closely tied to Cassandra itself. Other > subprojects are so far exclusively for consumption by the Cassandra project > itself, and are all naturally coupled. > > Drivers however are inherently arms-length endeavours: we publish a protocol > specification, and driver maintainers implement it. They are otherwise > fairly independent, and while a dialogue is helpful it does > not need to be controlled by a single entity. Many drivers will continue to > be controlled by others, as they have been until now. We're of course able > to ensure there's a strong overlap of governance, which I think would be very > helpful, and something Curator and Zookeeper seem not to have managed. > > Looking at the Curator website, it also seems to pitch itself as a relatively > opinionated product, and much more than a driver. I hope the recipe for > conflict in our case is much more limited given the functional scope of a > driver - and anyway better avoided with more integrated, but still distinct > governance. > > That's not to say I don't see some value in the project controlling the > driver directly, I just worry about the above. > > > > On 22/04/2020, 21:25, "Nate McCall" <zznat...@gmail.com> wrote: > > On Thu, Apr 23, 2020 at 5:37 AM Benedict Elliott Smith > <bened...@apache.org> > wrote: > >> I welcome the donation, and hope we are able to accept all of the >> drivers. This is really great news IMO. >> >> I do however wonder if the project may be accumulating too many >> sub-projects? I wonder if it's time to think about splitting, and perhaps >> incubating a project for the drivers? >> > > This is a legit concern and good question, but I think this is more a > natural evolution of growing a project. There is precedent for this in > Spark, Beam, Hadoop and others who have a number of different repositories > under the general project umbrella. > > What I would like to avoid is a situation like with Apache Curator and > Apache Zookeeper. The former being a zookeeper client donation from Netflix > that came in as a top level project. From the peanut gallery, it seems like > that has been less than ideal a couple of times in the past coordinating > releases, trademarks and such with separate project management. > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
