The idea was to have a single driver sub-project. Even if the code bases are different we believe that it is important to keep the drivers together to retain cohesive API semantics and make sure they have similar functionality and feature support. In this scenario we would need only 3 PMC members for the governance. I am willing to be one of them.
For the committers, my understanding, based on subproject governance procedures, <https://lists.apache.org/thread/tgbqpq5x03b7ssoplccxompxj6d1gw90> was that they should be proposed directly to the PMC members. Is the vote for the CEP to be for all drivers, but we will introduce each > driver one by one? What determines when we are comfortable with one driver > subproject and can move on to accepting the next ? > The goal of the CEP is simply to ensure that the community is in favor of the donation. Nothing more. The plan is to introduce the drivers, one by one. Each driver donation will need to be accepted first by the PMC members, as it is the case for any donation. Therefore the PMC should have full control on the pace at which new drivers are accepted. Le mar. 30 mai 2023 à 12:22, Josh McKenzie <jmcken...@apache.org> a écrit : > Is the vote for the CEP to be for all drivers, but we will introduce each > driver one by one? What determines when we are comfortable with one driver > subproject and can move on to accepting the next ? > > Curious to hear on this as well. There's 2 implications from the CEP as > written: > > 1. The Java and Python drivers hold special importance due to their > language proximity and/or project's dependence upon them ( > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-8%3A+Datastax+Drivers+Donation#CEP8:DatastaxDriversDonation-Scope > ) > 2. Datastax is explicitly offering all 7 drivers for donation ( > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-8%3A+Datastax+Drivers+Donation#CEP8:DatastaxDriversDonation-Goals > ) > > This is the most complex contribution via CEP thus far from a governance > perspective; I suggest we chart a bespoke path to navigate this. Having a > top level indication of "the CEP is approved" logically separate from a > per-language indication of "the project is ready to absorb this language > driver now" makes sense to me. This could look like: > > * Vote on the CEP itself > * Per language (processing one at a time): > * identify 3 PMC members willing to take on the governance role for > the language driver > * Identify 2 contributors who are active on a given driver and > stepping forward for a committer role on the driver > * Vote on inclusion of that language driver in the project + commit > bits > * Integrate that driver into the project ecosystem (build, ci, docs, > etc) > > Not sure how else we could handle committers / contributors / PMC members > other than on a per-driver basis. > > On Tue, May 30, 2023, at 5:36 AM, Mick Semb Wever wrote: > > > Thank you so much Jeremy and Greg (+others) for all the hard work on this. > > > > At this point, we'd like to propose CEP-8 for consideration, starting the > process to accept the DataStax Java driver as an official ASF project. > > > > Is the vote for the CEP to be for all drivers, but we will introduce each > driver one by one? What determines when we are comfortable with one driver > subproject and can move on to accepting the next ? > > Are there key committers and contributors on each driver that want to be > involved? Should they be listed before the vote? > We also need three PMC for the new subproject. Are we to assign these > before the vote? > > > >
