I'm talking about pekkoInlineEnabled. There is discussion about only enabling this in CI. Releases are not done using CI. So when we release pekkoInlineEnabled will be false. It makes no sense to me to enable pekkoInlineEnabled at all if we don't intend the Pekko 1.1.0-M1 to have it enabled. It makes our snapshots where pekkoInlineEnabled=true different from the likely 1.1.0-M1 release.
On 2024/01/31 07:50:48 Matthew de Detrich wrote: > > If everyone feels that there may be risks with inline, can we add a > separate inline test in ci? Or even release a separate inline jar > specifically for daily SNAPSHOT preview versions. We can even write a test > in downstream projects such as pekko-http to test the performance > difference between inline and regular versions. > > I don't have an issue doing this to placate concerns but to be blunt since > there has been zero evidence of any actual risks (the correctness concerns > alluded to earlier was a miscommunication) I do see it as a worse middle > ground option that wouldn't alleviate anyones concerns from either side. > > As a related tidbit, one of the motivated reasons for me having the inliner > enabled by default locally (which re-iterating I now regret) was to help > weed out any potential issues, i.e. lower the risk > > > The main problem now is > that we can only prove that there are no problems with the parts covered by > our tests, but we really have no way to prove that there are no problems > with the parts not covered by our tests :( > > The coverage of our test suite is quite extensive especially considering > that we are extending an entire matrix to all of our projects now. However > what I want to get to is that the main point of releasing M1 with the > inliner > enabled is to do exactly that, i.e. get people to run it in more battle > tested > scenarios. > > If there is a problem we revert it, now that we have sbt-pekko-build its > fairly trivial to do so. > > On Wed, Jan 31, 2024 at 5:33 PM kerr <hepin1...@gmail.com> wrote: > > > If everyone feels that there may be risks with inline, can we add a > > separate inline test in ci? Or even release a separate inline jar > > specifically for daily SNAPSHOT preview versions. We can even write a test > > in downstream projects such as pekko-http to test the performance > > difference between inline and regular versions. The main problem now is > > that we can only prove that there are no problems with the parts covered by > > our tests, but we really have no way to prove that there are no problems > > with the parts not covered by our tests :( > > > > > -- > > 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
