So this has finally been completed, see https://github.com/apache/incubator-pekko-http/pull/150. Many thanks to everyone involved, it was a big group effort that took many years!
The PR also updated pekko-http to Scala 3.3 LTS which allows us to use the latest version of Parboiled2 that contains many of the upstreamed performance improvements that were originally only contained within akka/pekko's Parboiled2 fork (see https://github.com/apache/incubator-pekko-http/pull/150 and https://github.com/apache/incubator-pekko-http/issues/103). Regards On Sun, Apr 30, 2023 at 8:00 AM Matthew Benedict de Detrich < matthew.dedetr...@aiven.io> wrote: > > As a compromise, I created another branch similar to Arnout's, which > leads to the same outcome but only has a single merge to main commit > at the end. AFAICS that will show the history as two parallel lines > quite nicely without adding the clutter of the multiple merge commits. > > > > https://github.com/apache/incubator-pekko-http/compare/main...jrudolph:incubator-pekko-http:scala3-merged-simple?expand=1 > > This is much better from my side, don't have any objections here. > > On Thu, Apr 27, 2023 at 2:49 PM Johannes Rudolph < > johannes.rudo...@gmail.com> wrote: > >> We spent quite some effort to keep the extended history of the long >> running branch, so it would be a pity to lose all that. >> >> As a compromise, I created another branch similar to Arnout's, which >> leads to the same outcome but only has a single merge to main commit >> at the end. AFAICS that will show the history as two parallel lines >> quite nicely without adding the clutter of the multiple merge commits. >> >> >> https://github.com/apache/incubator-pekko-http/compare/main...jrudolph:incubator-pekko-http:scala3-merged-simple?expand=1 >> >> Johannes >> >> On Thu, Apr 27, 2023 at 1:17 PM Arnout Engelen <enge...@apache.org> >> wrote: >> > >> > On Mon, Apr 17, 2023 at 10:33 AM Matthew Benedict de Detrich >> > <matthew.dedetr...@aiven.io.invalid> wrote: >> > > My current objection stems from how many merge commits the PR has (see >> > > https://github.com/apache/incubator-pekko-http/pull/130), I haven't >> done a >> > > merge in Github UI for a while but if these remain in the git log >> after the >> > > merge commit (which I believe is the case) >> > >> > I also believe that is the case. >> > >> > > then it would add a huge amount of noise to the git log. >> > > >> > > Also in case people are not aware, as long as a git commit references >> a PR >> > > from Github, Github will store the branch/commits from the PR >> indefinitely >> > > so you can always view the original PR to see precise >> commits/attribution. >> > > This was also pointed out earlier when we were deciding on linear >> history >> > >> > Personally I'm not too worried about 'noise' in the git log, and think >> > it can be helpful to have it while diagnosing issues using tools other >> > than the GitHub web UI. That said, if it helps moving this feature >> > forward I'm OK with having it squashed as well :). >> > >> > As for the general question of merging before 1.0.x: I'd say the >> > trade-off is between: >> > * merge now: risks incompatibility between akka-http and pekko-http >> > 1.0.x, risks additional maintenance work to support Scala 2.12 and 3 >> > side-by-side >> > * postpone merge: risks discovering problems with supporting 2.x and 3 >> > side-by-side later (post-1.0.x) >> > >> > I think it would be attractive to merge it now, to find any problems >> > as early as possible (preferably before even releasing 1.0.x) >> > >> > >> > Kind regards, >> > >> > Arnout >> > >> > > On Sun, Apr 16, 2023 at 2:00 PM PJ Fanning <fannin...@gmail.com> >> wrote: >> > > >> > > > I think it is fair to treat this as an exception and do allow a >> merge >> > > > commit for this. >> > > > >> > > > On Sun, 16 Apr 2023 at 12:58, Matthew Benedict de Detrich >> > > > <matthew.dedetr...@aiven.io.invalid> wrote: >> > > > > >> > > > > My preference is for a squash commit with the Co-Authored-Tag >> (which as >> > > > > stated before would be automatic) but that's because personally I >> value >> > > > > linear history much more strongly. In addition to the Co-Authored >> tag, >> > > > more >> > > > > accurate/clear attribution can also be done within the >> > > > > squash commit message (i.e. main/original implementation done by >> X, fixes >> > > > > to work with newest version done by Y etc etc). >> > > > > >> > > > > On Sun, Apr 16, 2023 at 12:53 PM Johannes Rudolph < >> > > > > johannes.rudo...@gmail.com> wrote: >> > > > > >> > > > > > Yep, we will have to change this before this commit to be able >> to >> > > > merge. >> > > > > > >> > > > > > Matthew Benedict de Detrich <matthew.dedetr...@aiven.io >> .invalid> >> > > > schrieb >> > > > > > am >> > > > > > So., 16. Apr. 2023, 12:42: >> > > > > > >> > > > > > > > We should do a real merge commit here and not do any >> rebasing or >> > > > > > > squashing in this case to preserve the history and >> attribution as it >> > > > > > > is. >> > > > > > > >> > > > > > > I don't think this is possible because we have enforced linear >> > > > history >> > > > > > for >> > > > > > > all Pekko repos but squash/rebase does preserve attribution >> via the >> > > > > > > Co-Authored tag (see >> > > > > > > >> > > > > > > >> > > > > > >> > > > >> https://docs.github.com/en/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-with-multiple-authors >> > > > > > > ). >> > > > > > > By default if you do a squash/rebase on Github's web UI it >> will >> > > > > > > automatically add in the Co-Authored tags if it sees that >> there are >> > > > > > > multiple commits from different authors. >> > > > > > > >> > > > > > > The main downside here is the loss of granularity >> particularly when >> > > > > > doing a >> > > > > > > squash (i.e. you specifically lose which commits were done by >> whom). >> > > > > > > >> > > > > > > On Sun, Apr 16, 2023 at 12:18 PM Johannes Rudolph < >> > > > > > > johannes.rudo...@gmail.com> wrote: >> > > > > > > >> > > > > > > > I support merging now/soon for pekko 1.0.x. It introduces >> some >> > > > extra >> > > > > > > > maintenance burden especially to support 2.12 and 3 at the >> same >> > > > time. >> > > > > > > > On the other hand, the most risky parts that the branch >> introduces >> > > > for >> > > > > > > > Scala 2.x support have already been merged with the move to >> the >> > > > latest >> > > > > > > > upstream parboiled2 version. Maintaining the branch longer >> will >> > > > only >> > > > > > > > become more difficult. I will hopefully have another look >> at the >> > > > state >> > > > > > > > of the branch next week, but I think it should be in good >> shape. We >> > > > > > > > should do a real merge commit here and not do any rebasing >> or >> > > > > > > > squashing in this case to preserve the history and >> attribution as >> > > > it >> > > > > > > > is. >> > > > > > > > >> > > > > > > > Johannes >> > > > > > > > >> > > > > > > > On Sat, Apr 15, 2023 at 11:17 AM Matthew Benedict de Detrich >> > > > > > > > <matthew.dedetr...@aiven.io.invalid> wrote: >> > > > > > > > > >> > > > > > > > > So regarding this proposal specifically of merging the >> scala3 >> > > > branch >> > > > > > > into >> > > > > > > > > pekko-http main I am all for it. The risk is low and if >> there >> > > > are any >> > > > > > > > > potential issues its better we find them out now rather >> than >> > > > later >> > > > > > > > > considering its for a 1.0.x release. There are also >> performance >> > > > fixes >> > > > > > > > which >> > > > > > > > > we should reintroduce which have been removed when we >> moved to >> > > > > > upstream >> > > > > > > > > Parboiled2 >> > > > > > > > > >> > > > > > > > > > Granted you likely don't care all that much about what >> one >> > > > consumer >> > > > > > > > > thinks, >> > > > > > > > > but i wouldn't be surprised if others are in similar >> situations. >> > > > > > > > > >> > > > > > > > > > We're in a similar situation to Dave here. Do you have >> an >> > > > > > indication >> > > > > > > > for >> > > > > > > > > how long is left on the scala3 pekko-http support? >> > > > > > > > > >> > > > > > > > > I wouldn't be so rash, we actually care a lot about the >> users >> > > > (or at >> > > > > > > > least >> > > > > > > > > I do). The biggest problem we are experiencing is there >> is a lot >> > > > of >> > > > > > > > factors >> > > > > > > > > at play which are causing tensions. For example the >> original >> > > > plan was >> > > > > > > to >> > > > > > > > > make Pekko 1.0.0 as close as possible to Akka 2.6 BSL >> with no >> > > > > > > behavioural >> > > > > > > > > changes but when then realized there were changes which >> would be >> > > > for >> > > > > > > the >> > > > > > > > > better of the community. One example of such change is >> updating >> > > > > > Jackson >> > > > > > > > > (due to CVE's) which also forced us to upgrade from Scala >> 3.2. >> > > > > > > > > >> > > > > > > > > Then there are other factors at play such as Scala 3.3, >> there are >> > > > > > > > extremely >> > > > > > > > > strong arguments by many people (including Scala >> center/EPFL) >> > > > that >> > > > > > > Pekko >> > > > > > > > > should target Scala 3.3 since its a LTS. The core of the >> bind >> > > > here >> > > > > > > really >> > > > > > > > > is binary compatibility/stability. If we release Pekko >> 1.0.0 >> > > > with a >> > > > > > > > Scala 3 >> > > > > > > > > version, we are likely going to be stuck with that >> version for a >> > > > > > LOOONG >> > > > > > > > > time considering that we made an agreement that only >> > > > CVE's/critical >> > > > > > > fixes >> > > > > > > > > will be backported to 1.0.x branch. My personal overview >> of the >> > > > > > > situation >> > > > > > > > > is that at least technically speaking (i.e. aside from the >> > > > > > > > > license/header/legal issues) there isn't much to do. >> There is a >> > > > > > project >> > > > > > > > > with a brief overview of what needs to be done at >> > > > > > > > > https://github.com/orgs/apache/projects/220/views/1 so I >> would >> > > > say >> > > > > > as >> > > > > > > a >> > > > > > > > > very broad estimation there is probably 1-2 months of >> work which >> > > > > > should >> > > > > > > > > also line up well with a Scala 3.3 LTS release (that is >> expected >> > > > this >> > > > > > > > > month). There is also >> > > > > > > https://github.com/apache/incubator-pekko/pull/281 >> > > > > > > > > which we should make a discussion on, I will create a >> discussion >> > > > > > thread >> > > > > > > > for >> > > > > > > > > this. >> > > > > > > > > >> > > > > > > > > On a tangential note, a discussion should probably be >> made about >> > > > the >> > > > > > > > > evolution of the Pekko project in general wrt binary >> > > > > > > > > compatibility/stability. At the heart of these problems >> is the >> > > > > > > > expectation >> > > > > > > > > of extreme binary compatibility that is inherited from >> Akka and I >> > > > > > think >> > > > > > > > > there is merit in exploring whether such expectations is >> the >> > > > > > healthiest >> > > > > > > > for >> > > > > > > > > the project in general (i.e. should they be loosened a >> bit?). >> > > > > > > > > >> > > > > > > > > On Sat, Apr 15, 2023 at 1:33 AM Greg Methvin < >> gr...@apache.org> >> > > > > > wrote: >> > > > > > > > > >> > > > > > > > > > I support this proposal. Scala 3 support is something >> most >> > > > people >> > > > > > > want >> > > > > > > > in a >> > > > > > > > > > Scala library these days, so having it would make the >> 1.0.0 >> > > > release >> > > > > > > > feel >> > > > > > > > > > more complete, especially for new users. It would also >> allow >> > > > > > library >> > > > > > > > > > authors to publish new releases using the Scala 3 >> artifacts as >> > > > soon >> > > > > > > as >> > > > > > > > > > possible. >> > > > > > > > > > >> > > > > > > > > > The only real concern is how much it would delay the >> release. >> > > > If it >> > > > > > > did >> > > > > > > > > > cause a delay, I imagine we could put out a milestone >> release >> > > > with >> > > > > > > > > > everything except the Scala 3 support, to give people a >> chance >> > > > to >> > > > > > > start >> > > > > > > > > > migrating earlier? >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > On Fri, Apr 14, 2023 at 8:37 AM PJ Fanning < >> > > > fannin...@gmail.com> >> > > > > > > > wrote: >> > > > > > > > > > >> > > > > > > > > > > incubator-pekko release is not dependent on anything >> in >> > > > > > > > > > > incubator-pekko-http. The original discussion has >> nothing to >> > > > do >> > > > > > > with >> > > > > > > > core >> > > > > > > > > > > pekko. incubator-pekko will be released when they are >> ready. >> > > > > > > > > > > incubator-pekko-http will be released separately, >> some time >> > > > later >> > > > > > > > when it >> > > > > > > > > > > is ready. If you want to discuss incubator-pekko, >> please >> > > > start a >> > > > > > > new >> > > > > > > > mail >> > > > > > > > > > > thread. >> > > > > > > > > > > >> > > > > > > > > > > On Fri 14 Apr 2023, 17:27 Sam Byng, >> > > > > > <samb...@microsoft.com.invalid >> > > > > > > > >> > > > > > > > > > wrote: >> > > > > > > > > > > >> > > > > > > > > > > > We're in a similar situation to Dave here. Do you >> have an >> > > > > > > > indication >> > > > > > > > > > for >> > > > > > > > > > > > how long is left on the scala3 pekko-http support? >> > > > > > > > > > > > >> > > > > > > > > > > > The positives on our side are that we don't have to >> wait >> > > > for >> > > > > > > pekko >> > > > > > > > > > 1.1.0 >> > > > > > > > > > > > to get pekko-http, and it makes further releases of >> > > > connectors >> > > > > > > etc >> > > > > > > > > > > simpler. >> > > > > > > > > > > > However, negatives would be the possible extension >> of 1.0.0 >> > > > > > date. >> > > > > > > > So >> > > > > > > > > > far, >> > > > > > > > > > > > looking at the MR it seems that adding pekko-http >> scala3 >> > > > > > support >> > > > > > > > is not >> > > > > > > > > > > far >> > > > > > > > > > > > off so wouldn't extend the 1.0.0 release too >> dramatically. >> > > > > > > > > > > > >> > > > > > > > > > > > -Sam >> > > > > > > > > > > > >> > > > > > > > > > > > > -----Original Message----- >> > > > > > > > > > > > > From: Dave Brosius <mebigfat...@gmail.com> >> > > > > > > > > > > > > Sent: Friday, April 14, 2023 2:49 PM >> > > > > > > > > > > > > To: dev@pekko.apache.org >> > > > > > > > > > > > > Subject: Re: [DISCUSS] adding pekko-http scala3 >> support >> > > > now >> > > > > > for >> > > > > > > > > > v1.0.0 >> > > > > > > > > > > > release >> > > > > > > > > > > > > >> > > > > > > > > > > > > As a future simple consumer of Apache Pekko, i'd >> would >> > > > love >> > > > > > > > anything >> > > > > > > > > > > > that gets a published release sooner than later as >> our >> > > > > > corporate >> > > > > > > > > > > governance >> > > > > > > > > > > > is on our necks about using akka (even the > last >> o/s >> > > > variant) >> > > > > > > > because >> > > > > > > > > > of >> > > > > > > > > > > > the license change. We have 1 year from the >> announcement >> > > > (sept >> > > > > > > > 23) to >> > > > > > > > > > > > resolve. >> > > > > > > > > > > > > >> > > > > > > > > > > > > Granted you likely don't care all that much about >> what >> > > > one >> > > > > > > > consumer >> > > > > > > > > > > > thinks, but i wouldn't be surprised if others are in >> > > > similar >> > > > > > > > > > situations. >> > > > > > > > > > > > > >> > > > > > > > > > > > > On Wed, Apr 12, 2023 at 5:54 AM Nicolas Vollmar < >> > > > > > > > nvoll...@gmail.com> >> > > > > > > > > > > > wrote: >> > > > > > > > > > > > > >> > > > > > > > > > > > > I assume overall there weren't any (major) >> changes to >> > > > public >> > > > > > > > APIs for >> > > > > > > > > > > > > Scala 3, so merging it for 1.0.0 would be a small >> risk, >> > > > but >> > > > > > > also >> > > > > > > > > > > > > reduce burden of maintaining the branch and allow >> to ship >> > > > > > > Scala 3 >> > > > > > > > > > > > > support across the board with 1.0.0. I'd +1 that. >> > > > > > > > > > > > > >> > > > > > > > > > > > > On Tue, 11 Apr 2023 at 13:26, PJ Fanning < >> > > > > > fannin...@apache.org >> > > > > > > > >> > > > > > > > > > wrote: >> > > > > > > > > > > > > >> > > > > > > > > > > > > > Hi, >> > > > > > > > > > > > > > >> > > > > > > > > > > > > > I'd like to pitch the idea of just merging the >> > > > pekko-http >> > > > > > > > scala3 >> > > > > > > > > > > > > > support to main branch when it is ready and >> including >> > > > this >> > > > > > in >> > > > > > > > the >> > > > > > > > > > > > v1.0.0 release. >> > > > > > > > > > > > > > We have already made small-ish changes like >> using >> > > > Parboiled >> > > > > > > > jar and >> > > > > > > > > > > > > > upgrading Jackson. >> > > > > > > > > > > > > > >> > > > > > > > > > > > > > The scala3 changes don't make significant >> changes to >> > > > the >> > > > > > APIs >> > > > > > > > and >> > > > > > > > > > it >> > > > > > > > > > > > > feels >> > > > > > > > > > > > > > like adding the scala3 support now would not >> make >> > > > migration >> > > > > > > > from >> > > > > > > > > > > > > > Akka >> > > > > > > > > > > > > HTTP >> > > > > > > > > > > > > > much harder. Akka HTTP has released scala3 >> support (BSL >> > > > > > > > licensed) >> > > > > > > > > > > > > > but the release seems to have gone smoothly - >> without >> > > > much >> > > > > > > user >> > > > > > > > > > > > complaint. >> > > > > > > > > > > > > Nothing >> > > > > > > > > > > > > > significant had to be documented about the >> migration to >> > > > > > Akka >> > > > > > > > HTTP >> > > > > > > > > > > > > > 10.4 >> > > > > > > > > > > > > [1]. >> > > > > > > > > > > > > > >> > > > > > > > > > > > > > My main reason for supporting an early merge of >> this is >> > > > > > that >> > > > > > > it >> > > > > > > > > > will >> > > > > > > > > > > > > > save us a whole circle of releases downstream. >> A scala3 >> > > > > > > support >> > > > > > > > > > > > > > pekko-http >> > > > > > > > > > > > > > v1.1.0 would lead to new releases for >> pekko-connectors >> > > > and >> > > > > > > > other >> > > > > > > > > > > > > downstream >> > > > > > > > > > > > > > projects. >> > > > > > > > > > > > > > >> > > > > > > > > > > > > > I get that we want to make migration to v1.0.0 >> easy >> > > > but I >> > > > > > > don't >> > > > > > > > > > > > > > think the >> > > > > > > > > > > > > > scala3 changes make this significantly harder. >> > > > > > > > > > > > > > >> > > > > > > > > > > > > > If we had made faster progress with the v1.0.0 >> release >> > > > then >> > > > > > > > being >> > > > > > > > > > > > > > conservative probably makes sense but now that >> we still >> > > > > > don't >> > > > > > > > have >> > > > > > > > > > a >> > > > > > > > > > > > > > release scheduled, it feels like we might be >> better off >> > > > > > > > planning to >> > > > > > > > > > > > > > get a slightly bigger v1.0.0 release done and >> saving >> > > > > > > ourselves >> > > > > > > > the >> > > > > > > > > > > > > > hassle of having to do a v1.1.0 release for the >> scala3 >> > > > > > > changes. >> > > > > > > > > > > > > > >> > > > > > > > > > > > > > [1] >> > > > > > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > >> > > > > > > >> > > > >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoc. >> > > > > > > > > > > > > akka.io >> > > > > > > > > > >> %2Fdocs%2Fakka-http%2Fcurrent%2Fmigration-guide%2Fmigration-gui >> > > > > > > > > > > > > >> de-10.4.x.html%23general-notes&data=05%7C01%7Csambyng% >> > > > > > > > > > 40microsoft.com% >> > > > > > > > > > > > > >> > > > > > > > > > >> > > > > > > >> > > > >> 7C84d3391cb35f40598c2908db3ceefd85%7C72f988bf86f141af91ab2d7cd011db47% >> > > > > > > > > > > > > >> > > > > > > > > > >> > > > > > > >> > > > >> 7C1%7C0%7C638170769415330544%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM >> > > > > > > > > > > > > >> > > > > > > > > > >> > > > > > > >> > > > >> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdat >> > > > > > > > > > > > > >> > > > > > > > >> a=9kKrhjPaZVGmWaV%2FPcF%2BygzMZjd%2BzXwNpCIuQxyD%2FcY%3D&reserved=0 >> > > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > > > >> > > > > > >> -------------------------------------------------------------------- >> > > > > > > > > > > > > > - To unsubscribe, e-mail: >> > > > dev-unsubscr...@pekko.apache.org >> > > > > > > For >> > > > > > > > > > > > > > additional commands, e-mail: >> dev-h...@pekko.apache.org >> > > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > >> > > > >> --------------------------------------------------------------------- >> > > > > > > > > > > > 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 >> > > > > > > > >> > > > > > > > >> > > > >> --------------------------------------------------------------------- >> > > > > > > > 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 >> > >> > >> > >> > -- >> > Arnout Engelen >> > ASF Security Response >> > Committer on Apache Pekko >> > Committer on NixOS >> > Independent Open Source consultant >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org >> > For additional commands, e-mail: dev-h...@pekko.apache.org >> > >> >> --------------------------------------------------------------------- >> 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
