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
