GOGOGOGO 何品
Matthew de Detrich <matthew.dedetr...@aiven.io.invalid> 于2024年1月23日周二 07:19写道： > I would also like to add > https://github.com/apache/incubator-pekko/pull/981 > onto the list > for M1. When originally making the feature request I incorrectly assumed > that > Supervision.Resume didn't make sense however that turns out to not be the > case. > > I think the basis of the feature is already implemented in the PR, just > need to add tests > and update documentation. > > On Mon, Jan 15, 2024 at 4:13 PM kerr <hepin1...@gmail.com> wrote: > > > Should we support limit the max forkjoinpool in 1.1.x? there is a pending > > pr, I think it would be nice to included in. > > > > Virtual thread can limit it with ` > > -Djdk.virtualThreadScheduler.maxPoolSize=256"` > > > > 何品 > > > > > > Matthew de Detrich <matthew.dedetr...@aiven.io.invalid> 于2024年1月15日周一 > > 09:33写道： > > > > > Regarding mult-release JAR support, I did some initial work[1] and I > > think > > > that this > > > will have to wait, possible for SBT 2.x since there are fundamental > > > limitations in sbt > > > to properly support this. > > > > > > Note that its still technically possible, but in doing so we have to > > > statically define > > > a set of keys (i.e. SBT SettingKey) for **every** JDK version that we > > want > > > to build > > > and since we are already at JDK 21 this can get unwieldy pretty > quickly. > > > > > > [1] > > > > > > > > > https://github.com/sbt/sbt-multi-release-jar/issues/24#issuecomment-1891156070 > > > > > > On Wed, Jan 10, 2024 at 11:06 AM Matthew de Detrich < > > > matthew.dedetr...@aiven.io> wrote: > > > > > > > So I have some good news for one of the big ticket items listed > > earlier, > > > > Pekko is now using the latest version of sbt-osgi which contains a > lot > > of > > > > fixes and > > > > improvements, see https://github.com/apache/incubator-pekko/pull/920 > . > > > > This avoids > > > > us having to drop sbt-osgi support (doing so is not off the table > > > > completely but should > > > > be made as a community decision later). Also > > > > https://github.com/apache/incubator-pekko/pull/252 > > > > landed which is important since it's a behavioural change. > > > > > > > > I would say the only other big item that should be handled before an > M1 > > > > vote is > > > > finishing off the inliner changes, > > > > https://github.com/apache/incubator-pekko/pull/587 > > > > and the migration of akka to pekko clusters. A milestone release of > > these > > > > changes > > > > will provide ample opportunity for extensive testing to make sure as > > much > > > > as possible > > > > that the full release is without issues. I left out multi-release-jar > > > > support, my feeling is > > > > that this is too big of a change for M1 but It might make sense as > an > > M2 > > > > or as part of 1.2.x. > > > > > > > > If there is anything that's left out please mention it. > > > > > > > > On Sun, Dec 24, 2023 at 7:42 AM kerr <hepin1...@gmail.com> wrote: > > > > > > > >> +1 for this, IIRC Matthew suggested this kind of release too. > > > >> 何品 > > > >> > > > >> > > > >> Matthew de Detrich <matthew.dedetr...@aiven.io.invalid> > > 于2023年12月13日周三 > > > >> 07:06写道： > > > >> > > > >> > Apologies for necroing this topic, but there is one other feature > I > > > >> would > > > >> > like to add to the M1 > > > >> > milestone release which is > > > >> > https://github.com/apache/incubator-pekko/pull/252. The reason I > > > >> > am pointing out this issue specifically is that it is a breaking > > > >> behaviour > > > >> > change (all of the > > > >> > details are in the PR) so it needs to land for the 1.1.x series, > > > ideally > > > >> > for M1 so we can figure > > > >> > out if there are any behavioural regressions. > > > >> > > > > >> > On Mon, Nov 6, 2023 at 8:40 PM Matthew de Detrich < > > > >> > matthew.dedetr...@aiven.io> wrote: > > > >> > > > > >> > > > Some of those changes will likely also need backporting for > > > >> > > 1.0.x releases. > > > >> > > > > > >> > > Indeed, the rolling migration from Akka to Pekko clusters is > > > actually > > > >> a > > > >> > > feature for 1.0.x, but because > > > >> > > of how its designed (i.e. there is a configuration for the > > > >> > sender/receiver > > > >> > > address), this feature and > > > >> > > configuration also needs to exist for Pekko 1.1.0 otherwise the > > user > > > >> > > experience will be extremely > > > >> > > unintuitive. > > > >> > > > > > >> > > > I don't think a 1.1.0-M0 is warranted. This git tag has code > > that > > > is > > > >> > > very similar to Pekko 1.0.1. I don't see the merit in having > > > multiple > > > >> > > ASF contributors having to review such a release. > > > >> > > > > > >> > > It trivializes MiMa management which is worth the annoyance of > > > doing a > > > >> > > release. There really > > > >> > > isn't any other way without breaking ASF policy, we basically > have > > > to > > > >> > make > > > >> > > a release that is > > > >> > > not a "real" release. > > > >> > > > > > >> > > One thing to note is this doesn't occur that frequently (i.e. M0 > > > >> > > milestones), i.e. its only on a > > > >> > > minor version bump and it can be argued that this release can be > > > part > > > >> of > > > >> > > the formality of > > > >> > > when we decide to make a 1.1.x branch, i.e. the community makes > a > > > >> > > decision/vote that > > > >> > > at a certain point in time we are going to bump the minor > version > > > >> which > > > >> > > requires a vote > > > >> > > and that some vote is also used for the M0 release. > > > >> > > > > > >> > > In fact, now that I think/write about it, we really should have > a > > > >> formal > > > >> > > vote when we make a > > > >> > > minor version bump because it is a significant change, it > > shouldn't > > > be > > > >> > > done at whim (even > > > >> > > if its from a PMC) > > > >> > > > > > >> > > > When I say LTS, I mean what versions will get patches for a > long > > > >> time. > > > >> > > Java releases are a good example. If an org really needs a Java > 22 > > > >> > > feature they can use Java 22 in production - but they are > expected > > > to > > > >> > > upgrade to Java 23, etc. when those versions are released until > a > > > new > > > >> > > Java LTS is released. There are other OSS equivalents. I am not > > > >> > > talking about Commercial Support contracts - commercial entities > > are > > > >> > > very welcome to fill this gap - this does not need to relate > > > directly > > > >> > > to the FOSS releases from the ASF project team. > > > >> > > > > > >> > > I understand the difference between LTS and commercial contract, > > > it's > > > >> > just > > > >> > > that > > > >> > > even the variables for how long the support is, is something > that > > I > > > >> don't > > > >> > > think > > > >> > > we have any ability to estimate concretely now. In summary, in > my > > > view > > > >> > > it's too > > > >> > > soon to even be discussing this. > > > >> > > > > > >> > > > If the consensus is to delay Pekko 1.1 until every candidate > > > change > > > >> is > > > >> > > made - then fine - but this stops users from using features that > > are > > > >> > > ready to try, like the Netty 4 support. > > > >> > > > > > >> > > As discussed on the github issue[1], this is a non issue. A > > > milestone > > > >> > > release > > > >> > > will cater to anyone who really needs netty4 and as stated, it's > > > just > > > >> as > > > >> > > tested > > > >> > > as any other Pekko release is. If people are really desperate > for > > > >> netty4, > > > >> > > then > > > >> > > they can use the milestone (I would also note that I haven't > seen > > > any > > > >> > > indication that anyone is begging for netty4 right now). > > > >> > > > > > >> > > > Since Pekko 1.1.0 full release seems like a long way away, it > > > might > > > >> be > > > >> > > worth considering mechanisms to release the most useful changes > > > >> > > earlier - in a way that Pekko 1.0 users can uptake. > > > >> > > > > > >> > > This is what milestones are for, i.e. they are precisely the > > > mechanism > > > >> > > to solve this issue. It also solves a host of other issues as > > > >> discussed > > > >> > > here[2]. > > > >> > > > > > >> > > [1] https://github.com/apache/incubator-pekko/pull/778 > > > >> > > [2] > > > https://lists.apache.org/thread/o494q89hhg64r5nwv4rnq6fsx9zofmny > > > >> > > > > > >> > > On Sun, Nov 5, 2023 at 10:57 PM PJ Fanning <fannin...@gmail.com > > > > > >> wrote: > > > >> > > > > > >> > >> I have no objections to the general list of changes that we > need > > > for > > > >> > >> 1.1.0. Some of those changes will likely also need backporting > > for > > > >> > >> 1.0.x releases. > > > >> > >> > > > >> > >> A 1.1.0-M1 release makes sense. I want to delay it by a week > or 2 > > > >> > >> while we decide what to do about the config logging (recent > Akka > > > >> CVE). > > > >> > >> > > > >> > >> I don't think a 1.1.0-M0 is warranted. This git tag has code > that > > > is > > > >> > >> very similar to Pekko 1.0.1. I don't see the merit in having > > > multiple > > > >> > >> ASF contributors having to review such a release. > > > >> > >> > > > >> > >> I guess it is a separate conversation but there is a fair > degree > > of > > > >> > >> resistance to us dropping support for anything. I think we will > > > need > > > >> > >> to only drop support if it really makes things much easier for > > us. > > > >> > >> Multi Release Jars seems like a better option than dropping > Java > > 8 > > > >> > >> support (for instance). > > > >> > >> > > > >> > >> When I say LTS, I mean what versions will get patches for a > long > > > >> time. > > > >> > >> Java releases are a good example. If an org really needs a Java > > 22 > > > >> > >> feature they can use Java 22 in production - but they are > > expected > > > to > > > >> > >> upgrade to Java 23, etc. when those versions are released > until a > > > new > > > >> > >> Java LTS is released. There are other OSS equivalents. I am not > > > >> > >> talking about Commercial Support contracts - commercial > entities > > > are > > > >> > >> very welcome to fill this gap - this does not need to relate > > > directly > > > >> > >> to the FOSS releases from the ASF project team. > > > >> > >> > > > >> > >> If the consensus is to delay Pekko 1.1 until every candidate > > change > > > >> is > > > >> > >> made - then fine - but this stops users from using features > that > > > are > > > >> > >> ready to try, like the Netty 4 support. > > > >> > >> > > > >> > >> Since Pekko 1.1.0 full release seems like a long way away, it > > might > > > >> be > > > >> > >> worth considering mechanisms to release the most useful changes > > > >> > >> earlier - in a way that Pekko 1.0 users can uptake. > > > >> > >> > > > >> > >> > > > >> > >> On Sun, 5 Nov 2023 at 12:59, Matthew de Detrich > > > >> > >> <matthew.dedetr...@aiven.io.invalid> wrote: > > > >> > >> > > > > >> > >> > So my take on this > > > >> > >> > > > > >> > >> > - We should do milestones to solve the general problem you > are > > > >> > alluding > > > >> > >> to, > > > >> > >> > i.e. the M1 milestone that you suggest that we vote on (we > > should > > > >> also > > > >> > >> do > > > >> > >> > the M0 milestone which is at the exact moment when a new bump > > to > > > >> minor > > > >> > >> > version is done, reasoning why is given in this thread[1]). I > > > would > > > >> > >> argue > > > >> > >> > that doing an M1 now is a good idea and then an M2 once other > > > >> critical > > > >> > >> > features land (such as inliner which is mentioned in the > below > > > >> point) > > > >> > >> > - There are some critical features that need to be merged > > before > > > a > > > >> > >> release > > > >> > >> > of 1.1.0 Pekko Core is ever made (and 1.1.0 Pekko core needs > to > > > be > > > >> > >> released > > > >> > >> > before any other 1.1.0 releases for the other modules) due to > > > >> > technical > > > >> > >> > reasons. On the top of my head the critical features so far > are > > > the > > > >> > >> > inliner[2] and rolling update migration of Akka to Pekko > > > >> clusters[3]. > > > >> > I > > > >> > >> > think it's achievable to get [2] and [3] done in a few months > > > time, > > > >> > but > > > >> > >> we > > > >> > >> > would have to focus on getting it over the line ([2] is > already > > > >> > "done", > > > >> > >> it > > > >> > >> > just needs a review and testing in downstream modules, [3] > > likely > > > >> > needs > > > >> > >> > more work and most of all testing so that it works as > > expected). > > > >> > >> > - Regarding LTS, I don't think we should entertain the idea > > now. > > > We > > > >> > >> have no > > > >> > >> > idea of what and how an LTS can work and we don't even have > the > > > >> > capacity > > > >> > >> > for it. It might even be a thing that LTS's are "someone > > else's" > > > >> > problem > > > >> > >> > (Pekko is open source after all). I think the most critical > > thing > > > >> is > > > >> > >> > sticking to semantic versioning, such an expectation is > > > manageable > > > >> for > > > >> > >> us > > > >> > >> > and I would argue is kind of a requirement for large open > > source > > > >> > >> projects > > > >> > >> > like Pekko > > > >> > >> > - Fixing the manager name [4] should also be fixed for 1.1.0 > > > >> (actually > > > >> > >> if > > > >> > >> > anything this should be fixed for 1.0.x branch as well) > > > >> > >> > - As kind of a stretch goal, sbt-multi-release-jar support > for > > > >> > 1.1.0[5] > > > >> > >> > would be awesome as it would unblock a **lot** of things > while > > > also > > > >> > >> keeping > > > >> > >> > part of the community happy > > > >> > >> > - Releasing pekko 1.1.0 with the latest sbt-osgi (which > > > apparently > > > >> > >> fixes a > > > >> > >> > lot of pain points versus the current osgi used in Pekko > 1.0.x) > > > >> would > > > >> > be > > > >> > >> > another nice stretch goal, currently there is one issue with > > > >> duplicate > > > >> > >> > classes but we now have infrastructure set up[6] so that we > can > > > >> > properly > > > >> > >> > test such changes. > > > >> > >> > > > > >> > >> > Note that a lot of the underlying reasoning behind my points > > are > > > >> also > > > >> > >> > strategic, i.e. keeping features which can be considered > > critical > > > >> to > > > >> > >> Pekko > > > >> > >> > and/or current Akka users which don't require to much effort > > > >> > (basically > > > >> > >> > anything that gives a reason for people to use/migrate to > Pekko > > > >> while > > > >> > >> not > > > >> > >> > breaking the i.e. our bank so to speak). I know that there > has > > > >> been a > > > >> > >> push > > > >> > >> > to do things like drop JDK 8, Scala 2.12, osgi etc etc due to > > > death > > > >> > by a > > > >> > >> > thousand cuts but tbh objectively speaking these issues are > not > > > >> taking > > > >> > >> up > > > >> > >> > that much time (at least personally by far the largest amount > > of > > > >> time > > > >> > >> spent > > > >> > >> > is just overhead of having to do so many releases and > validate > > > >> them, > > > >> > >> really > > > >> > >> > looking forward to the day when we can automate everything > with > > > >> > >> > sbt-reproducible-builds/jardiff/create jars in ci etc etc). > > Pekko > > > >> > 2.0.x > > > >> > >> > series is when we can look forward to drop a lot of this > > > "annoying > > > >> > >> > maintenance" stuff and I would actually strongly argue that > at > > > the > > > >> > time > > > >> > >> > when we start looking at Pekko 2.0.x we actually get a better > > > idea > > > >> of > > > >> > >> what > > > >> > >> > our Pekko users look like, because as has been shown due to > the > > > >> chaos > > > >> > >> > created from the license change very few us had any somewhat > > > >> realistic > > > >> > >> lens > > > >> > >> > as to how the Pekko community (specifically users) look like, > > > i.e. > > > >> > while > > > >> > >> > the OS would **LOVE** to get rid of JDK 1.8 support it just > so > > > >> happens > > > >> > >> that > > > >> > >> > a lot of people still need to use JDK 1.8 and even though > there > > > are > > > >> > >> reasons > > > >> > >> > to move away from 1.8 evidently they aren't relevant. > > > >> > >> > > > > >> > >> > [1] > > > >> https://lists.apache.org/thread/o494q89hhg64r5nwv4rnq6fsx9zofmny > > > >> > >> > [2] https://github.com/apache/incubator-pekko/pull/305 > > > >> > >> > [3] https://github.com/apache/incubator-pekko/pull/765 > > > >> > >> > [4] https://github.com/apache/incubator-pekko/pull/587 > > > >> > >> > [5] https://github.com/sbt/sbt-multi-release-jar/issues/22 > > > >> > >> > [6] https://github.com/apache/incubator-pekko/issues/75 > > > >> > >> > > > > >> > >> > On Sun, Nov 5, 2023 at 12:12 PM PJ Fanning < > > fannin...@apache.org > > > > > > > >> > >> wrote: > > > >> > >> > > > > >> > >> > > The core pekko repo [1] has quite a few changes in its main > > > >> branch > > > >> > >> that > > > >> > >> > > are are targeted at a future 1.1.0 release. > > > >> > >> > > > > > >> > >> > > We haven't really agreed on what to do with the code that > was > > > >> > already > > > >> > >> > > deprecated in the Akka era and there is also the issue of > the > > > >> > >> ApiMayChange > > > >> > >> > > annotations on some of the APIs. > > > >> > >> > > > > > >> > >> > > There are also some new features that developers want to > add. > > > >> > >> > > > > > >> > >> > > We don't have a great deal of developer effort available to > > us. > > > >> > >> > > > > > >> > >> > > I suspect that we need to need to balance the need to > release > > > >> some > > > >> > of > > > >> > >> the > > > >> > >> > > 1.1 changes and then maybe try to make another batch of > > changes > > > >> in > > > >> > >> Pekko > > > >> > >> > > 1.2. > > > >> > >> > > > > > >> > >> > > What if we aimed to do a Pekko 1.1.0 release in a few > months > > > and > > > >> > said > > > >> > >> that > > > >> > >> > > it was not a Long Term Support release? If we go down this > > > line, > > > >> we > > > >> > >> would > > > >> > >> > > probably want to have a tentative plan as to when a new LTS > > > >> release > > > >> > >> would > > > >> > >> > > happen. > > > >> > >> > > > > > >> > >> > > An example of something that would be useful to release > would > > > be > > > >> the > > > >> > >> > > netty4 support. I know that the Apache Flink team would > like > > to > > > >> use > > > >> > >> this. > > > >> > >> > > > > > >> > >> > > Alternatively, we could do a Pekko 1.1.0-M1 release. I > > suspect > > > >> that > > > >> > we > > > >> > >> > > would end up with a fair number of these and the M version > > > number > > > >> > >> would > > > >> > >> > > discourage uptake (except for testing). > > > >> > >> > > > > > >> > >> > > What are people's thoughts on the options? > > > >> > >> > > > > > >> > >> > > > > > >> > >> > > > > > >> > >> > > [1] https://github.com/apache/incubator-pekko > > > >> > >> > > > > > >> > >> > > > > > >> > > > --------------------------------------------------------------------- > > > >> > >> > > 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 > > > >> > >> > > > > >> > >> > Alexanderufer 3-7, 10117 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 > > > >> > > > > > >> > > Alexanderufer 3-7, 10117 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 > > > >> > > > > >> > Alexanderufer 3-7, 10117 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 > > > > > > > > Alexanderufer 3-7, 10117 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 > > > > > > Alexanderufer 3-7, 10117 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 > > Alexanderufer 3-7, 10117 Berlin > > Amtsgericht Charlottenburg, HRB 209739 B > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > *m:* +491603708037 > > *w:* aiven.io *e:* matthew.dedetr...@aiven.io >
