I agree with PJ fanning when it comes to adding the module right now, we simply don't have the capacity and there are way too many things on our plate. However when a release occurs and things stabilize a little more it is a different circumstance which is where I get to
> After that, I would probably start arguing to REDUCE the Apache Pekko code base as opposed to increase it. There are a lot of connectors that have broken tests or tests disabled. It's hard enough to support and test the core Pekko features (like Actors, Clustering, HTTP, etc.), while then also having to maintain all the integrations with a huge variety of 3rd party tools. It's taken us 8 months to release the Pekko core. We simply can't handle the enormous size of the current code base. We need to concentrate on the core tooling. So there are 2 views successful views here, one is that we grow Pekko along with our active contributors, which means that we add in more modules when they make technical sense but we also grow the number of active contributors so that this burden/maintenance can actually be handled. The other view is that we reduce the scope of what is in Pekko so that we can maintain what we currently have better. I currently lean for the former, and if we look at other projects like Flink and Airflow (which have more connectors than Pekko does) they do this and they do it successfully. If you boil it down, there isn't difference in the community that maintains a persistence-mongo thats external to Apache Pekko versus a community within Apache Pekko that maintains persistence-mongo. Which gets to the crux of this statement > Let the people who need the integrations (connectors and persistence implementations) maintain them. I would actually argue that our priority after release is to actually grow the community so that it can be maintained within Apache Pekko, so those people who need the integrations that you refer to actually become part of Pekko. It may have been in Lightbend's interest to restrict what Akka can accept in their org because their open source governance model didn't allow them to employ the community. Its well known that it was impossible to get maintainer/committer rights to any of Lightbends Akka's repos aside from Alpakka which actually and ironically got a large amount of support and contributions from the community considering how many connectors it supported. And I think there is a premise here, build some bridges plus a story and people will come. In summary, in my view it's too soon right now to add this right now. There is just way too much technical and process overhead when it comes to adding more repos. When those get solved then we can revisit it, in the meantime as PJ Fanning stated the akka dependencies of persistence-mongo for obvious reasons need to be moved over to pekko (and that's before we even get to the core persistence-mongo library) so whatever is decided shouldn't block you either way, all we are saying is that we ourselves don't have capacity to do the work now. On Mon, Jul 17, 2023 at 8:13 PM PJ Fanning <fannin...@gmail.com> wrote: > When I checked akka-persistence-mongo at the weekend, it has a > dependency on reactivemongo-akkastream which has a dependency on > reactivemongo (which also has an akka dependency). > > This might have changed for the pekko equivalent. > > Even if it has, I'm still going to argue against Apache Pekko taking > on any more code until we get the current code set of Pekko modules > released. And that will take months. > > After that, I would probably start arguing to REDUCE the Apache Pekko > code base as opposed to increase it. There are a lot of connectors > that have broken tests or tests disabled. It's hard enough to support > and test the core Pekko features (like Actors, Clustering, HTTP, > etc.), while then also having to maintain all the integrations with a > huge variety of 3rd party tools. It's taken us 8 months to release the > Pekko core. We simply can't handle the enormous size of the current > code base. We need to concentrate on the core tooling. Let the people > who need the integrations (connectors and persistence implementations) > maintain them. > > On Mon, 17 Jul 2023 at 18:30, Brendan Doyle <bdoyle0...@gmail.com> wrote: > > > > That’s fine I expected that to be the outcome for the reasons you listed, > > but wanted to raise the discussion. Though I am curious what you mean by > > the lib dependencies that don’t support pekko, which library dependencies > > are you referring to within? The maintainers of the akka mongo > persistence > > library have already successfully ported a pekko repo which I linked , > > they’re just working through some artifact publishing issues before a > > release happens. > > > > On Mon, Jul 17, 2023 at 10:03 AM PJ Fanning <fannin...@gmail.com> wrote: > > > > > I'd be a strong -1 on this. > > > > > > Maybe in distant future. > > > > > > There are too many lib dependencies in that module. None of which > support > > > Pekko. > > > > > > Software brought into ASF requires permissions from all the past > > > contributors. Pekko itself is an exception because of the Akka license > > > change. > > > > > > ASF requires us to do loads of process work and read every line to > check > > > its origin in case of licensing issues. Everything required multiple > votes. > > > > > > Why don't you start by talking to the existing lib maintainers about > them > > > releasing Pekko libs? If that doesn't work out, you could fork them > > > yourself. > > > > > > Pekko team have far too much code and too few active developers to > become a > > > shelter for all the old Akka libs that no-one wants to maintain. > > > > > > On Mon 17 Jul 2023, 17:31 Brendan Doyle, <bdoyle0...@gmail.com> wrote: > > > > > > > Whoops forgot to include the link to the repo. > > > > > > > > https://github.com/scullxbones/pekko-persistence-mongo > > > > > > > > > > > > On Mon, Jul 17, 2023 at 9:26 AM Brendan Doyle <bdoyle0...@gmail.com> > > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > The skullxbones mongo persistence library was the de facto > connector > > > for > > > > > mongo, never having a dedicated library from Lightbend. The creator > > > and a > > > > > collaborator have already successfully ported the library to pekko > > > 1.0.0 > > > > > and are working on getting a release out. The port has dropped > support > > > > for > > > > > reactive mongo and only using the official mongo-scala-driver going > > > > > forward. They would like to see the library donated to pekko if the > > > > > community / team would be interested. I know there’s a couple > official > > > > > persistence libraries for widely used db’s like dynamodb, > personally > > > > though > > > > > biased I would argue mongo falls into that category. I’m not sure > what > > > > the > > > > > bar or threshold is to take in another repo or if there’s a long > term > > > > plan > > > > > to combine persistence drivers into a single repo like the way > stream > > > > > connectors are set up besides kafka. > > > > > > > > > > Thanks, > > > > > Brendan > > > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > For additional commands, e-mail: dev-h...@pekko.apache.org > > -- Matthew de Detrich *Aiven Deutschland GmbH* Immanuelkirchstraße 26, 10405 Berlin Amtsgericht Charlottenburg, HRB 209739 B Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen *m:* +491603708037 *w:* aiven.io *e:* matthew.dedetr...@aiven.io
