To step out of the weeds a bit - other than the Zookeeper / Curator example, does anyone know of any other apache projects that have either subprojects or complementary sideprojects they're interdependent upon in their ecosystems? I'd like to reach out to some other pmc's for advice and feedback on this topic since there's no sense in reinventing the wheel if other projects have wisdom to share on this.
On Mon, Apr 27, 2020 at 12:42 PM Joshua McKenzie <jmcken...@apache.org> wrote: > re: ML noise, how hard would it be to filter out JIRA updates w/component > "Drivers"? Or from JIRA queries? > > For governance, I see it cutting both ways. If we have two separate > projects and ML's for drivers and C*, how do we keep a coherent view of new > features and roadmap stuff? Do we have CEP's for both projects and tie them > together? Do we drive changes in the driver feature ecosystem via CEP's in > C*? > > In the Venn diagram of overlap vs. non between the two projects, I see > there being more overlap than not. > > On Mon, Apr 27, 2020 at 12:34 PM Dinesh Joshi <djo...@apache.org> wrote: > >> >> >> > On Apr 27, 2020, at 2:50 AM, Sylvain Lebresne <lebre...@gmail.com> >> wrote: >> > >> > Fwiw, I agree with the concerns raised by Benedict, and think we should >> > carefully think about how this is handled. Which isn't not a rejection >> of >> > the donation in any way. >> > >> > Drivers are not small projects, and the majority of their day to day >> > maintenance is unrelated to the server (and the reverse is true). >> > >> > From the user point of view, I think it would be fabulous that Cassandra >> > appears like one project with a server and some official drivers, with >> one >> > coherent website and documentation for all. I'm all for striving for >> that. >> >> +1 >> >> > Behind the scenes however, I feel tings should be setup so that some >> amount >> > of >> > separation remains between server and whichever drivers are donated and >> > accepted, or I'm fairly sure things would get messy very quickly[1]). >> In my >> >> Can you say more about what "getting messy very quickly" means here? >> >> > mind that means *at a minimum*: >> > - separate JIRA projects. >> > - dedicated _dev_ (and commits) mailing lists. >> >> If we're thinking through how this would be setup, initially we had the >> same Jira project for sidecar but now there is a separate one to track >> sidecar specific jiras. At the moment we do not have a separate mailing >> list. I think Cassandra dev mailing list's volume is low enough to keep >> using the same ML. There is an added value that it gives visibility and >> developers don't need to go between multiple mailing lists. >> >> > But it's also worth thinking whether a single pool of committers/PMC >> > members is >> > desirable. >> > >> > Tbc, I'm not sure what is the best way to achieve this within the >> > constraint of >> > the Apache fundation, and maybe I'm just stating the obvious here. >> > >> > >> > [1] fwiw, I say this as someone that at some points in time was >> > simultaneously >> > somewhat actively involved in both Cassandra and the DataStax Java >> driver. >> > >> > -- >> > Sylvain >> > >> > >> > On Fri, Apr 24, 2020 at 12:54 AM 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 >> >>
