> Lomig Mégard has expressed an interest in continuing to maintain pekko-http-cors - so for me that would be a strong argument for not bringing this code inside Pekko. There is no guarantee that he will grant us the code.
That's a fair point, but this can also be reversed into a positive which is that he already has bought into the pekko ecosystem and if we bring his module into our code than his contributions will definitely be welcomed and its a path to him becoming a committer. Increasingly having these conversations is making me lean towards making a vote thread on the mailing list because we have to tread carefully especially with our messaging. Lets see what others say and then I can possible start a voting thread later in the week On Tue, May 30, 2023 at 4:02 PM PJ Fanning <fannin...@gmail.com> wrote: > I still think that the extra modules should be discussed separately. > There are alternatives that we could do in some cases. > > pekko-http-cors is probably the best module for us to start with > because Pekko HTTP will probably be released soon and there are not > many alternatives for this. > Lomig Mégard has expressed an interest in continuing to maintain > pekko-http-cors - so for me that would be a strong argument for not > bringing this code inside Pekko. There is no guarantee that he will > grant us the code. > > Not creating new repos and using existing repos does cut down a lot of > the overhead. But there is still plenty of overhead. > > > > On Tue, 30 May 2023 at 14:52, Matthew Benedict de Detrich > <matthew.dedetr...@aiven.io.invalid> wrote: > > > > Sorry I also forgot to mention one additional thing regarding voting, > aside > > from possibly creating a vote on whether to embark on this in the first > > place is there any > > additional voting necessary,either from us or the PPMC or otherwise? I > > assumed that if > > we have a code grant then additional votes are not really necessary or is > > the argument > > here that because we did accept a code donation then on those grounds > only > > the PPMC > > might not vote for the release hence triggering more blockages? > > > > On Tue, May 30, 2023 at 3:48 PM Matthew Benedict de Detrich < > > matthew.dedetr...@aiven.io> wrote: > > > > > > > > * we have all the work to change the package names and configs > > > * new documentation > > > * new CI builds > > > * a lot more votes on releases > > > > > > Incase there is a misunderstanding, I am not suggesting that we make > new > > > repos for any of the mentioned dependencies so > > > points such as new CI builds are not entirely relevant (if we want to > be > > > precise for pekko-http-cors it would just reuse the > > > existing pekko-http build which just builds all modules at once since > this > > > is the base case and for aws-spi-pekko-http this would > > > be a separate CI instance however that is just due to how > pekko-connectors > > > are structured, in other words adding this is literally > > > a single line in > > > > https://github.com/apache/incubator-pekko-connectors/blob/main/.github/workflows/check-build-test.yml#L86-L133 > > > ). > > > I don't think extra CI instances for a project like pekko-connectors in > > > the grand scheme of things is an issue, it already has like ~20 > > > integrations so one more isn't going to have a noticeable impact. > > > > > > The package name changes are likewise trivial compared to what we had > to > > > do with Pekko's modules just due to how much less > > > code we are dealing with and regarding config changes > aws-spik-pekko-http > > > doesn't even have any real configs (just a `META-INF.services` > > > in the resources folder which I think is pointless because its already > > > generated????) and with pekko-http-cors we just need to change a > > > single line, i.e. > > > > https://github.com/lomigmegard/pekko-http-cors/blob/ec10651cc754cb2aa86a4e120056d3067db3179a/pekko-http-cors/src/main/resources/reference.conf#L8 > > > > > > In summary aside from the documentation, unless I have missed something > > > all things considering technically speaking > > > this is actually not that much more work. > > > > > > The bigger issue which I think we should focus on is the > > > legal/vote/process parts, i.e. > > > > > > > * we would need to persuade the original contributors to grant the > code > > > to ASF and get it voted on (Pekko community and Incubator PMC) > > > > > > So the question here is, how should we approach this? If we decide to > go > > > ahead with this, the first obvious practical step is to > > > reach out to the author of pekko-http-cors to see if he is willing to > > > donate the code to ASF and sign a code grant. Shall we start > > > a voting round whether to initiate this in the first place so that we > are > > > all onboard with this? > > > > > > On Tue, May 30, 2023 at 3:21 PM PJ Fanning <fannin...@apache.org> > wrote: > > > > > >> Just to make clear to everyone - this does not affect the core Pekko > > >> modules and the proposal to press on with getting a RC ready. > > >> > > >> I agree that we should not consider taking anything into Pekko that we > > >> don't use inside our own modules - that is, only ones that Matthew > > >> mentioned are under discussion. > > >> > > >> At a high level, I'm not against taking in the listed modules but it > is a > > >> lot of work. > > >> * we would need to persuade the original contributors to grant the > code > > >> to ASF and get it voted on (Pekko community and Incubator PMC) > > >> * we have all the work to change the package names and configs > > >> * new documentation > > >> * new CI builds > > >> * a lot more votes on releases > > >> > > >> We should really consider alternatives on a cases by case basis. > > >> * one example is pekko-http-circe - Matthew has highlighted a JAWN > based > > >> lib that might be a good alternative > > >> * aws-spi-pekko-http - an alternative is to use the Java APIs in the > AWS > > >> v2 libs (which have good async support) > > >> > > >> All in all, I wouldn't regard taking any of these jars into the Pekko > > >> community as something that would block releases. For me, they might > be > > >> nice to have been the time expenditure on making the changes makes we > wary. > > >> > > >> > > >> On 2023/05/30 09:50:34 Matthew Benedict de Detrich wrote: > > >> > While the timing of this can be considered ill-advised considering > we > > >> have > > >> > a release candidate down the line, this is something that I have > only > > >> > somewhat recently discovered as I have been working on getting other > > >> Pekko > > >> > modules ready for releases. > > >> > > > >> > What I have noticed is that various Pekko modules (thankfully > > >> > excluding Pekko core) happen to have dependencies on other projects > > >> which > > >> > in turn also happen to depend on Pekko. This basically creates a > > >> transitive > > >> > circular dependency, i.e. Pekko Http has a dependency on project X > and > > >> > project X has a dependency on Pekko core. > > >> > > > >> > In my view this situation isn't really ideal because it opens us to > > >> risk of > > >> > being blocked when having to do some changes and this is what we > have > > >> > actually experienced when working on getting Pekko modules ready for > > >> > release candidates ( > > >> https://github.com/lomigmegard/pekko-http-cors/pull/19, > > >> > https://github.com/pjfanning/aws-spi-pekko-http/pull/6, > > >> > https://github.com/pjfanning/aws-spi-pekko-http/pull/5 and > > >> > https://github.com/pjfanning/aws-spi-pekko-http/pull/1) are > examples of > > >> > this. > > >> > > > >> > The problematic dependencies are listed below but in a lot of cases > PJ > > >> > Fanning has had to fork the project's and it's at this point that I > am > > >> > raising whether it makes more sense to just put the dependencies > > >> directly > > >> > inside the appropriate Pekko module. Note that the list below is > sorted > > >> in > > >> > criticality (i.e. modules closer to Pekko core are placed earlier > since > > >> > they will be released earlier). > > >> > > > >> > * https://github.com/lomigmegard/pekko-http-cors: This is not > forked > > >> by PJ > > >> > Fanning because thankfully the maintainer has been > > >> constructive/responsive > > >> > in adapting the project for Pekko and merging necessary changes. The > > >> > project is used by pekko-grpc but it depends on pekko-http since its > > >> adding > > >> > cors (see https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS). > The > > >> > natural place for this project would be to sit inside of > pekko-http, in > > >> > fact I am quite surprised that this is in a separate project since > this > > >> is > > >> > a W3C http standard. Adding this as a separate artifact inside of > > >> > pekko-http would technically be quite trivial. > > >> > * https://github.com/pjfanning/aws-spi-pekko-http is an SPI > (Service > > >> > Provider Interface) to AWS's async API for their services which is a > > >> fork > > >> > of https://github.com/matsluni/aws-spi-akka-http which is currently > > >> forked > > >> > by PJ Fanning. The project depends on pekko-http and is a > dependency of > > >> > various pekko-connecter AWS integrations (i.e. event bridge, > kinesis etc > > >> > etc). It can be its own artifact within pekko-connectors since its > > >> > transitive dependencies (i.e. aws sdk) are quite stable and don't > break > > >> > that often. > > >> > * https://github.com/hseeberger/akka-http-json: An integration > between > > >> Akka > > >> > Streams and Circe. The project depends on akka-http and is being > used by > > >> > the IronMQ integration in Pekko connectors, currently the project is > > >> forked > > >> > by PJ Fanning. I wouldn't recommend merging this project into > > >> > pekko-connectors because historically Circe's interface hasn't been > that > > >> > stable (more specifically Circe is still on 0.x on early-semver > which > > >> means > > >> > any increase in minor breaks binary compatibility and hence we > would be > > >> > forced to release pekko-connectors very frequently). If the author > > >> > considers forking this for Pekko than this is acceptable however > there > > >> are > > >> > alternatives, i.e. I maintain > > >> > https://github.com/mdedetrich/akka-streams-json which will be > forked > > >> in a > > >> > new repo for Pekko once a change in typelevel's jawn is released > (and > > >> as a > > >> > bonus akka-streams-json which will be pekko-streams-circe as an > actual > > >> > streaming JSON implementation, unlike akka-http-json) > > >> > > > >> > Including the source of these plugins directly into Pekko raises a > lot > > >> of > > >> > concerns. The most obvious ones are legal/license, on the licensing > > >> front > > >> > we are lucky since all of the code in question is Apache 2 however > there > > >> > can be other legal concerns that always arise in these cases. > > >> > > > >> > Thankfully we are a bit lucky here in that the author of the most > > >> critical > > >> > module dependency timewise pekko-http-cors has been very open in > working > > >> > with us, so it may not even be a stretch in proactively and honestly > > >> asking > > >> > him whether he would be willing to donate the code (even with a code > > >> grant) > > >> > to us which I would presume would solve most legal issues. The other > > >> > dependency which is aws-spi-pekko-http might be a bit more > problematic > > >> but > > >> > its also part of pekko-connectors which will take some time before > we > > >> get > > >> > to a release and by that time pekko core would already have its > 1.0.x > > >> > release which hopefully increase chances of the author being more > > >> > responsive to us. As mentioned before akka-http-json doesn't make > sense > > >> > because of technical reasons but we should look into approaching the > > >> author > > >> > at some point in making it support pekko irregardless of what we > decide > > >> on > > >> > this topic. > > >> > > > >> > Also finally regarding the effort both in including the code and in > > >> > maintaining it, with the former we would just place code in an > existing > > >> > repository. Even for purely technical reasons it doesn't make sense > to > > >> make > > >> > the projects their own repo and in regards to maintenance burden a > lot > > >> of > > >> > this code is basically unchanged for years so we should be good > here. > > >> > > > >> > What is everyones thoughts on this? > > >> > > > >> > -- > > >> > > > >> > 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 > > >> > > > >> > > >> --------------------------------------------------------------------- > > >> 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 > > > > > > > > > -- > > > > 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 > > --------------------------------------------------------------------- > 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
