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
