@Justin Mclean, do you have any comments on this, at least wrt any legal/ASF/PPMC implications?
On Tue, 30 May 2023, 16:07 Matthew Benedict de Detrich, < matthew.dedetr...@aiven.io> wrote: > > 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 >
