You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@pekko.apache.org by Matthew Benedict de Detrich <ma...@aiven.io.INVALID> on 2023/05/08 06:37:07 UTC
Plans for Pekko (core) 1.0.0 release
Johannes, PJ Fanning and myself had a discussion last week to regarding
future plans regarding the Pekko 1.0.0 release, below are the generate
points discussed on this topic
* We should focus on doing a Pekko release first for the core module
* In terms of actual technical work that needs to be done for a future
first release, there doesn't appear to be a lot. The last main piece of
work should be https://github.com/apache/incubator-pekko/pull/281. There is
also Scala 3.3 LTS but considering there is already an open PR for RC4 on
this (see https://github.com/apache/incubator-pekko/pull/270) and RC4 is
expected to be the last RC before release, this shouldn't be a concern. The
main thing to look at here is the docker image that Johannes made to help
in creating a release (see
https://github.com/apache/incubator-pekko/pull/188)
* There are still open questions regarding legal questions (i.e. headers)
but considering feedback is given on this by the community on a voluntary
basis, its best to start off the release sooner rather than later to
trigger/solicit some proper feedback on this topic otherwise we would be
waiting for an extortionate amount of time.
* Users of Akka looking to transition to Pekko have raised concerns
regarding the release schedule and how long it's taking. While it is true
that the release is taking a long amount of time, it should be pointed out
that this shouldn't be indicative of future releases. In other words, a
large reason why the release is taking a long amount of time is that we had
to deliberate, discuss, plan and actually develop the Apache release
process for the first time. Pekko is also a hard fork which is never easy
and the current release process is reflecting that.
* It was pointed out that the health of the current contributors isn't the
best (i.e. majority of work is being done by a few people). While there are
various factors behind this (such as work necessary for first release
requires a lot of SBT knowledge, something that only a few people can
provide right now) the bigger point to be made here is that its a chicken
and egg situation ergo potential contributors are holding back because they
want confidence in the Pekko project before devoting their time however for
the project to be more successful we need more contributors for the first
release.
* We have decided to publish a MILESTONE in the snapshots repository to
provide an indication that a release is coming soon. This will occur after
https://github.com/apache/incubator-pekko/pull/270, also because
https://github.com/apache/incubator-pekko/pull/270 will require downstream
changes to every Pekko module (and its easier to refer to a MILESTONE
version rather than just git hashes).
* Documentation for the rest of the Pekko modules should be published but
we shouldn't worry too much about getting the versioning of the docs
correct. Having something there is better than nothing, especially
considering that documentation is the first thing that users look for.
Additional comments are welcome.
--
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.dedetrich@aiven.io
Re: Plans for Pekko (core) 1.0.0 release
Posted by Alexandru Nedelcu <sp...@ac.alexn.org>.
👋 having a 1.0.0 would potentially unlock more contributions, because
the biggest barrier to adoption is lack of time; FOSS investments can be
more easily justified when the project is actively depended on at $work.
On 18 May 2023, at 21:47, Michael Seydel wrote:
> Same as Mehmet, I looked and found that it was non-coding blocking the
> 1.0
> release.
>
> On Wed, May 17, 2023 at 11:34 PM Mehmet Salgar <sa...@gmx.de>
> wrote:
>
>>> * It was pointed out that the health of the current contributors
>>> isn't the
>>> best (i.e. majority of work is being done by a few people). While
>>> there
>> are
>>> various factors behind this (such as work necessary for first
>>> release
>>> requires a lot of SBT knowledge, something that only a few people
>>> can
>>> provide right now) the bigger point to be made here is that its a
>>> chicken
>>> and egg situation ergo potential contributors are holding back
>>> because
>> they
>>> want confidence in the Pekko project before devoting their time
>>> however
>> for
>>> the project to be more successful we need more contributors for the
>>> first
>>> release.
>>
>> This will sound stupid but a while ago I tried to figure out what I
>> can do
>> for Pekko, while I was expecting that somebody would tell me take
>> this
>> Issue and fix/implement it, the answer was choose an issue and work
>> with
>> it, I looked for three issue s, later to discover other people are
>> working
>> on those and then there was some private stuff and I could not be
>> that
>> active with contributing.
>>
>> Now I have more time and am I looking ways to contribute, now is
>> there
>> anybody distributing issues or I still have to figure something
>> myself?
>>
>> Thx for answers...
>>
>>
>>
>> Gesendet: Montag, 08. Mai 2023 um 08:37 Uhr
>> Von: "Matthew Benedict de Detrich"
>> <ma...@aiven.io.INVALID>
>> An: dev@pekko.apache.org, users@pekko.apache.org
>> Betreff: Plans for Pekko (core) 1.0.0 release
>> Johannes, PJ Fanning and myself had a discussion last week to
>> regarding
>> future plans regarding the Pekko 1.0.0 release, below are the
>> generate
>> points discussed on this topic
>>
>> * We should focus on doing a Pekko release first for the core module
>> * In terms of actual technical work that needs to be done for a
>> future
>> first release, there doesn't appear to be a lot. The last main piece
>> of
>> work should be https://github.com/apache/incubator-pekko/pull/281.
>> There
>> is
>> also Scala 3.3 LTS but considering there is already an open PR for
>> RC4 on
>> this (see
>> https://github.com/apache/incubator-pekko/pull/270[https://github.com/apache/incubator-pekko/pull/270])
>> and RC4 is
>> expected to be the last RC before release, this shouldn't be a
>> concern. The
>> main thing to look at here is the docker image that Johannes made to
>> help
>> in creating a release (see
>>
>> https://github.com/apache/incubator-pekko/pull/188[https://github.com/apache/incubator-pekko/pull/188]
>> )
>> * There are still open questions regarding legal questions (i.e.
>> headers)
>> but considering feedback is given on this by the community on a
>> voluntary
>> basis, its best to start off the release sooner rather than later to
>> trigger/solicit some proper feedback on this topic otherwise we would
>> be
>> waiting for an extortionate amount of time.
>> * Users of Akka looking to transition to Pekko have raised concerns
>> regarding the release schedule and how long it's taking. While it is
>> true
>> that the release is taking a long amount of time, it should be
>> pointed out
>> that this shouldn't be indicative of future releases. In other words,
>> a
>> large reason why the release is taking a long amount of time is that
>> we had
>> to deliberate, discuss, plan and actually develop the Apache release
>> process for the first time. Pekko is also a hard fork which is never
>> easy
>> and the current release process is reflecting that.
>> * It was pointed out that the health of the current contributors
>> isn't the
>> best (i.e. majority of work is being done by a few people). While
>> there are
>> various factors behind this (such as work necessary for first release
>> requires a lot of SBT knowledge, something that only a few people can
>> provide right now) the bigger point to be made here is that its a
>> chicken
>> and egg situation ergo potential contributors are holding back
>> because they
>> want confidence in the Pekko project before devoting their time
>> however for
>> the project to be more successful we need more contributors for the
>> first
>> release.
>> * We have decided to publish a MILESTONE in the snapshots repository
>> to
>> provide an indication that a release is coming soon. This will occur
>> after
>>
>> https://github.com/apache/incubator-pekko/pull/270[https://github.com/apache/incubator-pekko/pull/270],
>> also because
>>
>> https://github.com/apache/incubator-pekko/pull/270[https://github.com/apache/incubator-pekko/pull/270]
>> will require downstream
>> changes to every Pekko module (and its easier to refer to a MILESTONE
>> version rather than just git hashes).
>> * Documentation for the rest of the Pekko modules should be published
>> but
>> we shouldn't worry too much about getting the versioning of the docs
>> correct. Having something there is better than nothing, especially
>> considering that documentation is the first thing that users look
>> for.
>>
>> Additional comments are welcome.
>>
>> --
>>
>> 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.dedetrich@aiven.io
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
>> For additional commands, e-mail: dev-help@pekko.apache.org
>>
>>
--
Alexandru Nedelcu
https://alexn.org
Re: Plans for Pekko (core) 1.0.0 release
Posted by li guobin <dr...@outlook.com>.
Strongly agree
发自我的 iPhone
> 在 2023年5月21日，10:49，Justin Mclean <ju...@classsoftware.com> 写道：
>
> Hi,
>
> IMO you are overdue for an initial release and are trying a little too hard to make it perfect. It doesn’t need to be perfect, each release just needs to be better than the last. Release early and release often as the saying goes.
>
> Kind Regards,
> Justin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@pekko.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org
Re: Plans for Pekko (core) 1.0.0 release
Posted by Matthew Benedict de Detrich <ma...@aiven.io.INVALID>.
> One of the criteria to vote on a release is to successfully compile it.
If it complex to do that or it requires prerequisites that people may not
use or be familiar with or not have installed that may make it hard to get
votes. Hopefully this won’t be an issue.
Understood, but as mentioned before there is nothing Pekko can do about
this. To properly build all of the artifacts within Pekko core for a
release it requires multiple JDK's to be installed at once on the host
machine (this is mainly due to a backwards breaking change that was
introduced in JDK 11 and Pekko currently supports JDK 8). Even if JDK 8
support gets dropped, there are other build/release specific features that
would need to be supplied (i.e. inlining). Note that I am making a
distinction between compiling and making a release build, currently nothing
is preventing people from compiling Pekko locally (this is how people
develop locally). However if we want to make a release build (which is in
the form of jar's) the steps detailed beforehand are necessary.
The whole reason why Docker is being used here is that it's a lot more
trivial compared to other options (i.e. VM's, documenting different
solutions for different OS's using different tools like sdkman etc).
On Mon, May 22, 2023 at 10:57 AM Justin Mclean <ju...@classsoftware.com>
wrote:
> Hi,
>
> One of the criteria to vote on a release is to successfully compile it. If
> it complex to do that or it requires prerequisites that people may not use
> or be familiar with or not have installed that may make it hard to get
> votes. Hopefully this won’t be an issue.
>
> Kind Regards,
> Justin
>
> > On 22 May 2023, at 5:14 pm, Matthew Benedict de Detrich <
> matthew.dedetrich@aiven.io.INVALID> wrote:
> >
> >> I’m not sure if this is the case, but requiring docker to check the
> > release may be a barrier to getting IPMC votes on your release.
> >
> > Docker is required to make a correct and reproducible build of Pekko
> > because Pekko requires multiple JDK's to be installed on the host
> > systems, if this is not the case then some parts of Pekko will simply
> fail
> > to work on some JDK's. While it is possible to inspect the final build
> > without Docker, due to the fact that Pekko's build is reproducible the
> > easiest way to confirm that the build is correct is by building Pekko via
> > the docker image on a system and then confirming that the final jar's are
> > the same as what the release manager is providing.
> >
> > While this may not be ideal, there also isn't any way around it at least
> if
> > you want to correctly build Pekko. Pekko is not a trivial system to build
> > and using Docker is far simpler than any alternative (at least that I
> know
> > of).
> >
> > On Mon, May 22, 2023 at 2:53 AM Justin Mclean <ju...@classsoftware.com>
> > wrote:
> >
> >> Hi,
> >>
> >>> The docker image is not a convenience package (this also foesnt make
> >> sense
> >>> since Pekko is a library), it's for creating a reproducible environment
> >> for
> >>> making a release. There are other ways to do this such as a VM image
> but
> >>> docker is the least friction solution.
> >>
> >> I’m not sure if this is the case, but requiring docker to check the
> >> release may be a barrier to getting IPMC votes on your release.
> >>
> >> Kind Regards,
> >> Justin
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> >> For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
Re: Plans for Pekko (core) 1.0.0 release
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
One of the criteria to vote on a release is to successfully compile it. If it complex to do that or it requires prerequisites that people may not use or be familiar with or not have installed that may make it hard to get votes. Hopefully this won’t be an issue.
Kind Regards,
Justin
> On 22 May 2023, at 5:14 pm, Matthew Benedict de Detrich <ma...@aiven.io.INVALID> wrote:
>
>> I’m not sure if this is the case, but requiring docker to check the
> release may be a barrier to getting IPMC votes on your release.
>
> Docker is required to make a correct and reproducible build of Pekko
> because Pekko requires multiple JDK's to be installed on the host
> systems, if this is not the case then some parts of Pekko will simply fail
> to work on some JDK's. While it is possible to inspect the final build
> without Docker, due to the fact that Pekko's build is reproducible the
> easiest way to confirm that the build is correct is by building Pekko via
> the docker image on a system and then confirming that the final jar's are
> the same as what the release manager is providing.
>
> While this may not be ideal, there also isn't any way around it at least if
> you want to correctly build Pekko. Pekko is not a trivial system to build
> and using Docker is far simpler than any alternative (at least that I know
> of).
>
> On Mon, May 22, 2023 at 2:53 AM Justin Mclean <ju...@classsoftware.com>
> wrote:
>
>> Hi,
>>
>>> The docker image is not a convenience package (this also foesnt make
>> sense
>>> since Pekko is a library), it's for creating a reproducible environment
>> for
>>> making a release. There are other ways to do this such as a VM image but
>>> docker is the least friction solution.
>>
>> I’m not sure if this is the case, but requiring docker to check the
>> release may be a barrier to getting IPMC votes on your release.
>>
>> Kind Regards,
>> Justin
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
>> For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org
Re: Plans for Pekko (core) 1.0.0 release
Posted by Matthew Benedict de Detrich <ma...@aiven.io.INVALID>.
> I’m not sure if this is the case, but requiring docker to check the
release may be a barrier to getting IPMC votes on your release.
Docker is required to make a correct and reproducible build of Pekko
because Pekko requires multiple JDK's to be installed on the host
systems, if this is not the case then some parts of Pekko will simply fail
to work on some JDK's. While it is possible to inspect the final build
without Docker, due to the fact that Pekko's build is reproducible the
easiest way to confirm that the build is correct is by building Pekko via
the docker image on a system and then confirming that the final jar's are
the same as what the release manager is providing.
While this may not be ideal, there also isn't any way around it at least if
you want to correctly build Pekko. Pekko is not a trivial system to build
and using Docker is far simpler than any alternative (at least that I know
of).
On Mon, May 22, 2023 at 2:53 AM Justin Mclean <ju...@classsoftware.com>
wrote:
> Hi,
>
> > The docker image is not a convenience package (this also foesnt make
> sense
> > since Pekko is a library), it's for creating a reproducible environment
> for
> > making a release. There are other ways to do this such as a VM image but
> > docker is the least friction solution.
>
> I’m not sure if this is the case, but requiring docker to check the
> release may be a barrier to getting IPMC votes on your release.
>
> Kind Regards,
> Justin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
Re: Plans for Pekko (core) 1.0.0 release
Posted by Matthew Benedict de Detrich <ma...@aiven.io.INVALID>.
Of course everyone is free to create their own setups for building Pekko
however the idea for the docker image is to create a multi
platform/architecture baseline that is easy to use/follow.
> Unfortunately it looks like the scala 3 artifacts will not be
bit-by-bit reproducible for now
Thanks for looking into this! Definitely something we should look out for,
and if this gets resolved I am quite sure it will be backported to Scala
3.3 LTS.
(https://github.com/lampepfl/dotty/issues/17330)
On Mon, May 22, 2023 at 2:10 PM Arnout Engelen <en...@apache.org> wrote:
> On Mon, May 22, 2023 at 2:53 AM Justin Mclean <ju...@classsoftware.com>
> wrote:
> > > The docker image is not a convenience package (this also foesnt make
> sense
> > > since Pekko is a library), it's for creating a reproducible
> environment for
> > > making a release. There are other ways to do this such as a VM image
> but
> > > docker is the least friction solution.
> >
> > I’m not sure if this is the case, but requiring docker to check the
> release may be a barrier to getting IPMC votes on your release.
>
> While I'm sure the docker image is a convenience for those who are
> happy to run it, I plan to also rebuild releases outside of it. Having
> the two JDK's available is a somewhat unusual requirement but not that
> hard to achieve - on most distro's it's likely a matter of installing
> them both, on NixOS I use the following `shell.nix`:
>
> ```
> { pkgs ? import <nixpkgs> {} }:
>
> pkgs.mkShell {
> buildInputs = [
> (pkgs.sbt.override {
> jre = pkgs.jdk11;
> })
> ];
> JAVA_8_HOME = "${pkgs.jdk8}/lib/openjdk";
> }
> ```
>
> The override to use jdk11 is probably not strictly needed, but there
> to be conservative.
>
> Of course I'm not on the IPMC, so this doesn't matter from the formal
> voting perspective, but I think it's healthy to test with a diverse
> set of build setups.
>
> Unfortunately it looks like the scala 3 artifacts will not be
> bit-by-bit reproducible for now
> (https://github.com/lampepfl/dotty/issues/17330)
>
>
> Arnout
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
Re: Plans for Pekko (core) 1.0.0 release
Posted by Arnout Engelen <en...@apache.org>.
On Mon, May 22, 2023 at 2:53 AM Justin Mclean <ju...@classsoftware.com> wrote:
> > The docker image is not a convenience package (this also foesnt make sense
> > since Pekko is a library), it's for creating a reproducible environment for
> > making a release. There are other ways to do this such as a VM image but
> > docker is the least friction solution.
>
> I’m not sure if this is the case, but requiring docker to check the release may be a barrier to getting IPMC votes on your release.
While I'm sure the docker image is a convenience for those who are
happy to run it, I plan to also rebuild releases outside of it. Having
the two JDK's available is a somewhat unusual requirement but not that
hard to achieve - on most distro's it's likely a matter of installing
them both, on NixOS I use the following `shell.nix`:
```
{ pkgs ? import <nixpkgs> {} }:
pkgs.mkShell {
buildInputs = [
(pkgs.sbt.override {
jre = pkgs.jdk11;
})
];
JAVA_8_HOME = "${pkgs.jdk8}/lib/openjdk";
}
```
The override to use jdk11 is probably not strictly needed, but there
to be conservative.
Of course I'm not on the IPMC, so this doesn't matter from the formal
voting perspective, but I think it's healthy to test with a diverse
set of build setups.
Unfortunately it looks like the scala 3 artifacts will not be
bit-by-bit reproducible for now
(https://github.com/lampepfl/dotty/issues/17330)
Arnout
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org
Re: Plans for Pekko (core) 1.0.0 release
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> The docker image is not a convenience package (this also foesnt make sense
> since Pekko is a library), it's for creating a reproducible environment for
> making a release. There are other ways to do this such as a VM image but
> docker is the least friction solution.
I’m not sure if this is the case, but requiring docker to check the release may be a barrier to getting IPMC votes on your release.
Kind Regards,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org
Re: Plans for Pekko (core) 1.0.0 release
Posted by Matthew Benedict de Detrich <ma...@aiven.io.INVALID>.
> With Scala 3.3.0, it's my opinion that we could do the M0 snapshot
publish before this is ready. I doubt whether a large proportion of the
people waiting for the release need Scala 3 support and the jars built with
Scala 3.2.2 are expected to work with Scala 3.3. Our Scala 3.3.0-RC6 build
did not show any significant issues. If Scala 3.3.0 is released shortly
after we do our M0 snapshot, we could uptake Scala 3.3.0 and possibly so a
M1 snapshot.
Scala 3.3 is expected to release early next week which is likely going to
be sooner than any milestone release.
Also do note there is another strong reason to have milestone for Scala
3.3, the upstreamed Parboiled2 changes from pekko-http will also only get
released alongside Scala 3.3.
> I'm not convinced that we need to do the inliner changes either [4]. Akka
build had them disabled and I'd prefer not wait to wait for the Scala fixes
to support them. One question I would have is if the Scala 3.3 `inline def`
changes are possibly something that we could merge now or do the `@inline`
annotations that they replace enough as is?
For all intents and purposes within Pekko the @inline in Scala 2 works the
same as inline keyword in Scala 3 and for this reason I wouldn't recommend
merging the inline changes unless we know its working for all of the Scala
versions we support (2.12 to 3.3). Currently it's working for Scala 2.12
and 3.
Another thing to note is that @inline does nothing in Scala 3 so we have to
replicate the the source for Scala 3 specifically.
Regarding qualms on the safety of inline, unlike the older Scala 2 inline
the latest one is not going to inline anything unless it's safe to do so
(which is actually the single problem we have right now, something which
should be inlined is not for 2.13).
Regardless its easy to verify if the inliner is causing problems by
inspecting the diff in JVM bytecode and the PR won't be merged unless this
is done, whether it makes it for 1.0.0 or not.
On Sun, 21 May 2023, 18:56 PJ Fanning, <fa...@apache.org> wrote:
> If anyone is looking to help push Pekko core libs [1] to a 1.0.0 release,
> the most useful thing to do is try out the latest snapshots [2].
>
> The plan is to do minimal changes unless big issues are found.
>
> With Scala 3.3.0, it's my opinion that we could do the M0 snapshot publish
> before this is ready. I doubt whether a large proportion of the people
> waiting for the release need Scala 3 support and the jars built with Scala
> 3.2.2 are expected to work with Scala 3.3. Our Scala 3.3.0-RC6 build did
> not show any significant issues. If Scala 3.3.0 is released shortly after
> we do our M0 snapshot, we could uptake Scala 3.3.0 and possibly so a M1
> snapshot.
>
> I'm not convinced that we need to do the inliner changes either [4]. Akka
> build had them disabled and I'd prefer not wait to wait for the Scala fixes
> to support them. One question I would have is if the Scala 3.3 `inline def`
> changes are possibly something that we could merge now or do the `@inline`
> annotations that they replace enough as is?
>
> If we could agree not to wait for these items, we could just do the M0
> snapshot in the next few days and look to do the 1.0.0 RC1 in maybe a week
> or 2's time.
>
> We have the MiMa plugin to check for binary compatibility issues after the
> 1.0.0 release. I think we can live with making some small binary
> incompatible changes if we document them. At the moment, it feels like we
> are damaging Pekko by not releasing.
>
> [1] https://github.com/apache/incubator-pekko
> [2]
> https://repository.apache.org/content/groups/snapshots/org/apache/pekko/
> [3] https://github.com/apache/incubator-pekko/pull/270
> [4] https://github.com/apache/incubator-pekko/pull/305
>
> On 2023/05/21 14:09:24 Matthew Benedict de Detrich wrote:
> > > A docker release is just a convenance to your users, it’s not an
> official
> > release.
> >
> > The docker image is not a convenience package (this also foesnt make
> sense
> > since Pekko is a library), it's for creating a reproducible environment
> for
> > making a release. There are other ways to do this such as a VM image but
> > docker is the least friction solution.
> >
> > > Why wait? The longer you do so the harder it may be to grow a community
> > around this project. Making releases involves the community, they can
> > provide feedback and make contributions to improve the project.
> >
> > Because since Pekko is a library that follows an ABI we can break users
> if
> > not careful and that is one of the most negative ways you can impact
> Pekko
> > users.
> >
> > > Perhaps the project needs to consider a change to this approach?
> >
> > This is an expectation for Scala/Java libraries so it's not really going
> to
> > change. It's not any different to Apache Commons also maintaining binary
> > compatibility (for example), it's just that it's harder for us since
> Pekko
> > is a cross Java/Scala library.
> >
> > On Sun, 21 May 2023, 15:00 Justin Mclean, <ju...@classsoftware.com>
> wrote:
> >
> > > Hi,
> > >
> > > > A lot of our complications for the release come from the fact that
> Pekko
> > > is
> > > > a library with very strict expectations for binary
> compatibility.(these
> > > > expectations are inherited from Akka).
> > >
> > > Perhaps the project needs to consider a change to this approach?
> > >
> > > > Thankfully as mentioned before the majority of the critical changes
> that
> > > > fulfil these expectations have already been done. Aside from further
> > > > documentation changes and getting the docker release working,
> > >
> > > A docker release is just a convenance to your users, it’s not an
> official
> > > release.
> > >
> > > > the major thing we are waiting for is Scala 3.3 LTS which is
> expected to
> > > come out
> > > > next week.
> > >
> > > Why wait? The longer you do so the harder it may be to grow a community
> > > around this project. Making releases involves the community, they can
> > > provide feedback and make contributions to improve the project.
> > >
> > > Kind Regards,
> > > Justin
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > For additional commands, e-mail: dev-help@pekko.apache.org
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@pekko.apache.org
>
>
Re: Plans for Pekko (core) 1.0.0 release
Posted by Matthew Benedict de Detrich <ma...@aiven.io.INVALID>.
Are we talking about critical issues with Scala 3.3 specifically or
critical issues in general? Afaik at least with Pekko core all critical
issues (recent example being Jackson update due to CVE) have been resolved,
if thats not the case then they should be reported and we have to make a
decision about whether to include it in 1.0.x or 1.1.x.
On Mon, May 22, 2023 at 5:40 AM kerr <he...@gmail.com> wrote:
> Sorry, I mean the first final release of pekko 1.0.0 should include fixes
> for critical issues.
> 何品s
>
>
> kerr <he...@gmail.com> 于2023年5月22日周一 11:37写道：
>
> > I think we should fix some critical issues before the final release of
> > 3.3.0, which was reported to the Akka repo but not pekko.
> > 何品
> >
> >
> > Justin Mclean <ju...@classsoftware.com> 于2023年5月22日周一 08:57写道：
> >
> >> Hi,
> >>
> >> > If anyone is looking to help push Pekko core libs [1] to a 1.0.0
> >> release, the most useful thing to do is try out the latest snapshots
> [2].
> >>
> >> That might help from a compatibility point of view, but not from an ASF
> >> release point of view. An ASF release needs to include certain things
> like
> >> a LICENSE and NOTICE file etc. Looking at one of those jars at random I
> can
> >> see that the META-INF directory doesn’t include a LICENSE or NOTICE
> file.
> >>
> >> Kind Regards,
> >> Justin
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> >> For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
Re: Plans for Pekko (core) 1.0.0 release
Posted by Matthew Benedict de Detrich <ma...@aiven.io.INVALID>.
> I prefer not to look at Akka repos, including their issues. We should
not be looking at the PRs. If we apply a fix to Pekko and it could be
construed that the fix is based on an Akka fix, there could be real
trouble.
Afaik looking at Akka issues/features is fine but looking at PR's is
definitely a no-go legally.
> If the person who submitted the PR to Akka can also be persuaded to
submit it to Pekko then the whole position is much simpler.
Agreed
> If there is anything critical to the Pekko 1.0.0 release, it should be
logged in Pekko issues tracker. If there is nothing logged there, we
will proceed to a 1.0.0 release.
Also agreed and as far as I understand there is nothing else that is
considered critical which hasn't already been discussed.
On Mon, May 22, 2023 at 12:03 PM PJ Fanning <fa...@gmail.com> wrote:
> I prefer not to look at Akka repos, including their issues. We should
> not be looking at the PRs. If we apply a fix to Pekko and it could be
> construed that the fix is based on an Akka fix, there could be real
> trouble.
>
> If the person who submitted the PR to Akka can also be persuaded to
> submit it to Pekko then the whole position is much simpler.
>
> If there is anything critical to the Pekko 1.0.0 release, it should be
> logged in Pekko issues tracker. If there is nothing logged there, we
> will proceed to a 1.0.0 release.
>
> On Mon, 22 May 2023 at 04:40, kerr <he...@gmail.com> wrote:
> >
> > Sorry, I mean the first final release of pekko 1.0.0 should include fixes
> > for critical issues.
> > 何品s
> >
> >
> > kerr <he...@gmail.com> 于2023年5月22日周一 11:37写道：
> >
> > > I think we should fix some critical issues before the final release of
> > > 3.3.0, which was reported to the Akka repo but not pekko.
> > > 何品
> > >
> > >
> > > Justin Mclean <ju...@classsoftware.com> 于2023年5月22日周一 08:57写道：
> > >
> > >> Hi,
> > >>
> > >> > If anyone is looking to help push Pekko core libs [1] to a 1.0.0
> > >> release, the most useful thing to do is try out the latest snapshots
> [2].
> > >>
> > >> That might help from a compatibility point of view, but not from an
> ASF
> > >> release point of view. An ASF release needs to include certain things
> like
> > >> a LICENSE and NOTICE file etc. Looking at one of those jars at random
> I can
> > >> see that the META-INF directory doesn’t include a LICENSE or NOTICE
> file.
> > >>
> > >> Kind Regards,
> > >> Justin
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > >> For additional commands, e-mail: dev-help@pekko.apache.org
> > >>
> > >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
Re: Plans for Pekko (core) 1.0.0 release
Posted by PJ Fanning <fa...@gmail.com>.
I prefer not to look at Akka repos, including their issues. We should
not be looking at the PRs. If we apply a fix to Pekko and it could be
construed that the fix is based on an Akka fix, there could be real
trouble.
If the person who submitted the PR to Akka can also be persuaded to
submit it to Pekko then the whole position is much simpler.
If there is anything critical to the Pekko 1.0.0 release, it should be
logged in Pekko issues tracker. If there is nothing logged there, we
will proceed to a 1.0.0 release.
On Mon, 22 May 2023 at 04:40, kerr <he...@gmail.com> wrote:
>
> Sorry, I mean the first final release of pekko 1.0.0 should include fixes
> for critical issues.
> 何品s
>
>
> kerr <he...@gmail.com> 于2023年5月22日周一 11:37写道：
>
> > I think we should fix some critical issues before the final release of
> > 3.3.0, which was reported to the Akka repo but not pekko.
> > 何品
> >
> >
> > Justin Mclean <ju...@classsoftware.com> 于2023年5月22日周一 08:57写道：
> >
> >> Hi,
> >>
> >> > If anyone is looking to help push Pekko core libs [1] to a 1.0.0
> >> release, the most useful thing to do is try out the latest snapshots [2].
> >>
> >> That might help from a compatibility point of view, but not from an ASF
> >> release point of view. An ASF release needs to include certain things like
> >> a LICENSE and NOTICE file etc. Looking at one of those jars at random I can
> >> see that the META-INF directory doesn’t include a LICENSE or NOTICE file.
> >>
> >> Kind Regards,
> >> Justin
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> >> For additional commands, e-mail: dev-help@pekko.apache.org
> >>
> >>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org
Re: Plans for Pekko (core) 1.0.0 release
Posted by kerr <he...@gmail.com>.
Sorry, I mean the first final release of pekko 1.0.0 should include fixes
for critical issues.
何品s
kerr <he...@gmail.com> 于2023年5月22日周一 11:37写道：
> I think we should fix some critical issues before the final release of
> 3.3.0, which was reported to the Akka repo but not pekko.
> 何品
>
>
> Justin Mclean <ju...@classsoftware.com> 于2023年5月22日周一 08:57写道：
>
>> Hi,
>>
>> > If anyone is looking to help push Pekko core libs [1] to a 1.0.0
>> release, the most useful thing to do is try out the latest snapshots [2].
>>
>> That might help from a compatibility point of view, but not from an ASF
>> release point of view. An ASF release needs to include certain things like
>> a LICENSE and NOTICE file etc. Looking at one of those jars at random I can
>> see that the META-INF directory doesn’t include a LICENSE or NOTICE file.
>>
>> Kind Regards,
>> Justin
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
>> For additional commands, e-mail: dev-help@pekko.apache.org
>>
>>
Re: Plans for Pekko (core) 1.0.0 release
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I think we should fix some critical issues before the final release of
> 3.3.0, which was reported to the Akka repo but not pekko
Which brings up an interesting question. How are those fixes licensed? What would be the general process for identifying and coming up with fixes without including code under a non compatible license?
Kind Regards,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org
Re: Plans for Pekko (core) 1.0.0 release
Posted by kerr <he...@gmail.com>.
I think we should fix some critical issues before the final release of
3.3.0, which was reported to the Akka repo but not pekko.
何品
Justin Mclean <ju...@classsoftware.com> 于2023年5月22日周一 08:57写道：
> Hi,
>
> > If anyone is looking to help push Pekko core libs [1] to a 1.0.0
> release, the most useful thing to do is try out the latest snapshots [2].
>
> That might help from a compatibility point of view, but not from an ASF
> release point of view. An ASF release needs to include certain things like
> a LICENSE and NOTICE file etc. Looking at one of those jars at random I can
> see that the META-INF directory doesn’t include a LICENSE or NOTICE file.
>
> Kind Regards,
> Justin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@pekko.apache.org
>
>
Re: Plans for Pekko (core) 1.0.0 release
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> If anyone is looking to help push Pekko core libs [1] to a 1.0.0 release, the most useful thing to do is try out the latest snapshots [2].
That might help from a compatibility point of view, but not from an ASF release point of view. An ASF release needs to include certain things like a LICENSE and NOTICE file etc. Looking at one of those jars at random I can see that the META-INF directory doesn’t include a LICENSE or NOTICE file.
Kind Regards,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org
Re: Plans for Pekko (core) 1.0.0 release
Posted by PJ Fanning <fa...@apache.org>.
If anyone is looking to help push Pekko core libs [1] to a 1.0.0 release, the most useful thing to do is try out the latest snapshots [2].
The plan is to do minimal changes unless big issues are found.
With Scala 3.3.0, it's my opinion that we could do the M0 snapshot publish before this is ready. I doubt whether a large proportion of the people waiting for the release need Scala 3 support and the jars built with Scala 3.2.2 are expected to work with Scala 3.3. Our Scala 3.3.0-RC6 build did not show any significant issues. If Scala 3.3.0 is released shortly after we do our M0 snapshot, we could uptake Scala 3.3.0 and possibly so a M1 snapshot.
I'm not convinced that we need to do the inliner changes either [4]. Akka build had them disabled and I'd prefer not wait to wait for the Scala fixes to support them. One question I would have is if the Scala 3.3 `inline def` changes are possibly something that we could merge now or do the `@inline` annotations that they replace enough as is?
If we could agree not to wait for these items, we could just do the M0 snapshot in the next few days and look to do the 1.0.0 RC1 in maybe a week or 2's time.
We have the MiMa plugin to check for binary compatibility issues after the 1.0.0 release. I think we can live with making some small binary incompatible changes if we document them. At the moment, it feels like we are damaging Pekko by not releasing.
[1] https://github.com/apache/incubator-pekko
[2] https://repository.apache.org/content/groups/snapshots/org/apache/pekko/
[3] https://github.com/apache/incubator-pekko/pull/270
[4] https://github.com/apache/incubator-pekko/pull/305
On 2023/05/21 14:09:24 Matthew Benedict de Detrich wrote:
> > A docker release is just a convenance to your users, it’s not an official
> release.
>
> The docker image is not a convenience package (this also foesnt make sense
> since Pekko is a library), it's for creating a reproducible environment for
> making a release. There are other ways to do this such as a VM image but
> docker is the least friction solution.
>
> > Why wait? The longer you do so the harder it may be to grow a community
> around this project. Making releases involves the community, they can
> provide feedback and make contributions to improve the project.
>
> Because since Pekko is a library that follows an ABI we can break users if
> not careful and that is one of the most negative ways you can impact Pekko
> users.
>
> > Perhaps the project needs to consider a change to this approach?
>
> This is an expectation for Scala/Java libraries so it's not really going to
> change. It's not any different to Apache Commons also maintaining binary
> compatibility (for example), it's just that it's harder for us since Pekko
> is a cross Java/Scala library.
>
> On Sun, 21 May 2023, 15:00 Justin Mclean, <ju...@classsoftware.com> wrote:
>
> > Hi,
> >
> > > A lot of our complications for the release come from the fact that Pekko
> > is
> > > a library with very strict expectations for binary compatibility.(these
> > > expectations are inherited from Akka).
> >
> > Perhaps the project needs to consider a change to this approach?
> >
> > > Thankfully as mentioned before the majority of the critical changes that
> > > fulfil these expectations have already been done. Aside from further
> > > documentation changes and getting the docker release working,
> >
> > A docker release is just a convenance to your users, it’s not an official
> > release.
> >
> > > the major thing we are waiting for is Scala 3.3 LTS which is expected to
> > come out
> > > next week.
> >
> > Why wait? The longer you do so the harder it may be to grow a community
> > around this project. Making releases involves the community, they can
> > provide feedback and make contributions to improve the project.
> >
> > Kind Regards,
> > Justin
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > For additional commands, e-mail: dev-help@pekko.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org
Re: Plans for Pekko (core) 1.0.0 release
Posted by Matthew Benedict de Detrich <ma...@aiven.io.INVALID>.
> A docker release is just a convenance to your users, it’s not an official
release.
The docker image is not a convenience package (this also foesnt make sense
since Pekko is a library), it's for creating a reproducible environment for
making a release. There are other ways to do this such as a VM image but
docker is the least friction solution.
> Why wait? The longer you do so the harder it may be to grow a community
around this project. Making releases involves the community, they can
provide feedback and make contributions to improve the project.
Because since Pekko is a library that follows an ABI we can break users if
not careful and that is one of the most negative ways you can impact Pekko
users.
> Perhaps the project needs to consider a change to this approach?
This is an expectation for Scala/Java libraries so it's not really going to
change. It's not any different to Apache Commons also maintaining binary
compatibility (for example), it's just that it's harder for us since Pekko
is a cross Java/Scala library.
On Sun, 21 May 2023, 15:00 Justin Mclean, <ju...@classsoftware.com> wrote:
> Hi,
>
> > A lot of our complications for the release come from the fact that Pekko
> is
> > a library with very strict expectations for binary compatibility.(these
> > expectations are inherited from Akka).
>
> Perhaps the project needs to consider a change to this approach?
>
> > Thankfully as mentioned before the majority of the critical changes that
> > fulfil these expectations have already been done. Aside from further
> > documentation changes and getting the docker release working,
>
> A docker release is just a convenance to your users, it’s not an official
> release.
>
> > the major thing we are waiting for is Scala 3.3 LTS which is expected to
> come out
> > next week.
>
> Why wait? The longer you do so the harder it may be to grow a community
> around this project. Making releases involves the community, they can
> provide feedback and make contributions to improve the project.
>
> Kind Regards,
> Justin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@pekko.apache.org
>
>
Re: Plans for Pekko (core) 1.0.0 release
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> A lot of our complications for the release come from the fact that Pekko is
> a library with very strict expectations for binary compatibility.(these
> expectations are inherited from Akka).
Perhaps the project needs to consider a change to this approach?
> Thankfully as mentioned before the majority of the critical changes that
> fulfil these expectations have already been done. Aside from further
> documentation changes and getting the docker release working,
A docker release is just a convenance to your users, it’s not an official release.
> the major thing we are waiting for is Scala 3.3 LTS which is expected to come out
> next week.
Why wait? The longer you do so the harder it may be to grow a community around this project. Making releases involves the community, they can provide feedback and make contributions to improve the project.
Kind Regards,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org
Re: Plans for Pekko (core) 1.0.0 release
Posted by Matthew Benedict de Detrich <ma...@aiven.io.INVALID>.
A lot of our complications for the release come from the fact that Pekko is
a library with very strict expectations for binary compatibility (these
expectations are inherited from Akka). To put things into perspective,
something like ~50-70% of all of the available public interfaces are
expected to be backwards compatible. Pekko being written in Scala also does
not make things easier (the story is better if we only care about Scala 3
but because of community expectations we are cross compiling from Scala
2.12 all the way to Scala 3).
So while an application (lets say a database) may only have to care about
the on-disk and the wire format when it comes to compatibility (to a
degree), with Pekko its significantly more. Being a library also means that
Pekko can also be used transitively in other projects, further complicating
matters.
Thankfully as mentioned before the majority of the critical changes that
fulfil these expectations have already been done. Aside from further
documentation changes and getting the docker release working, the major
thing we are waiting for is Scala 3.3 LTS which is expected to come out
next week (note that supporting Scala 3.3 LTS has a major impact for
Pekko's users and the Scala Center/EPFL, i.e. the people in charge of the
Scala language heavily recommended that libraries release with 3.3 LTS).
Scala 3 is not forwards compatible, so if we decided to release Pekko
before Scala 3.3 LTS we could have caused breakages for our users, whereas
Scala 3.3 LTS is expected to create a floor for the minimum supported Scala
3 version within the entire Scala 3 ecosystem.
I can say that especially if we are talking about Pekko core, we are seeing
the light at the end of the tunnel. The inliner is one thing that I would
have liked to get out before (see
https://github.com/apache/incubator-pekko/pull/305) mainly because it helps
deal with dropping Scala 2.12 (see
https://github.com/apache/incubator-pekko/pull/281) but it shouldn't block
the release.
On Sun, May 21, 2023 at 4:48 AM Justin Mclean <ju...@classsoftware.com>
wrote:
> Hi,
>
> IMO you are overdue for an initial release and are trying a little too
> hard to make it perfect. It doesn’t need to be perfect, each release just
> needs to be better than the last. Release early and release often as the
> saying goes.
>
> Kind Regards,
> Justin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
Re: Plans for Pekko (core) 1.0.0 release
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
IMO you are overdue for an initial release and are trying a little too hard to make it perfect. It doesn’t need to be perfect, each release just needs to be better than the last. Release early and release often as the saying goes.
Kind Regards,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org
Re: Plans for Pekko (core) 1.0.0 release
Posted by Matthew Benedict de Detrich <ma...@aiven.io.INVALID>.
Thanks for the interest,
While we may have the problem of having a few core contributors, it's
definitely the case that these few core contributors are
very active/aggressive when it comes to doing the features. This is for
obvious reasons, we want to get a release out as fast as possible and we
already received feedback before that the pace we are going at is extremely
fast.
In the past I have tried to encourage contributors to use the assigned
label in github issues so its clear if we are working on something (or not)
but especially as of recent we have been going so fast that in a lot of
cases we haven't even bothered to create issues to assign in the first
place!
The best way I can think of contributing at this current stage would be to
go through the various documentations for Pekko core with a fine tooth comb
to see if we have missed anything. Testing is also another obvious thing
which people have already taken up, if you want something a bit more
challenging there is also https://github.com/apache/incubator-pekko/pull/188,
although the PR is still a draft nothing is stopping people from trying it
out (the main thing we also want to confirm is that signing can be done
within the docker image, even if you are not a release manager you can try
out the signing with any key to confirm that it works).
We should also go through https://github.com/orgs/apache/projects/220 to
see if it's still up to date.
On Thu, May 18, 2023 at 8:48 PM Michael Seydel <mi...@gmail.com> wrote:
> Same as Mehmet, I looked and found that it was non-coding blocking the 1.0
> release.
>
> On Wed, May 17, 2023 at 11:34 PM Mehmet Salgar <sa...@gmx.de>
> wrote:
>
> > >* It was pointed out that the health of the current contributors isn't
> the
> > >best (i.e. majority of work is being done by a few people). While there
> > are
> > >various factors behind this (such as work necessary for first release
> > >requires a lot of SBT knowledge, something that only a few people can
> > >provide right now) the bigger point to be made here is that its a
> chicken
> > >and egg situation ergo potential contributors are holding back because
> > they
> > >want confidence in the Pekko project before devoting their time however
> > for
> > >the project to be more successful we need more contributors for the
> first
> > >release.
> >
> > This will sound stupid but a while ago I tried to figure out what I can
> do
> > for Pekko, while I was expecting that somebody would tell me take this
> > Issue and fix/implement it, the answer was choose an issue and work with
> > it, I looked for three issue s, later to discover other people are
> working
> > on those and then there was some private stuff and I could not be that
> > active with contributing.
> >
> > Now I have more time and am I looking ways to contribute, now is there
> > anybody distributing issues or I still have to figure something myself?
> >
> > Thx for answers...
> >
> >
> >
> > Gesendet: Montag, 08. Mai 2023 um 08:37 Uhr
> > Von: "Matthew Benedict de Detrich" <ma...@aiven.io.INVALID>
> > An: dev@pekko.apache.org, users@pekko.apache.org
> > Betreff: Plans for Pekko (core) 1.0.0 release
> > Johannes, PJ Fanning and myself had a discussion last week to regarding
> > future plans regarding the Pekko 1.0.0 release, below are the generate
> > points discussed on this topic
> >
> > * We should focus on doing a Pekko release first for the core module
> > * In terms of actual technical work that needs to be done for a future
> > first release, there doesn't appear to be a lot. The last main piece of
> > work should be https://github.com/apache/incubator-pekko/pull/281. There
> > is
> > also Scala 3.3 LTS but considering there is already an open PR for RC4 on
> > this (see
> >
> https://github.com/apache/incubator-pekko/pull/270[https://github.com/apache/incubator-pekko/pull/270]
> )
> > and RC4 is
> > expected to be the last RC before release, this shouldn't be a concern.
> The
> > main thing to look at here is the docker image that Johannes made to help
> > in creating a release (see
> >
> >
> https://github.com/apache/incubator-pekko/pull/188[https://github.com/apache/incubator-pekko/pull/188]
> > )
> > * There are still open questions regarding legal questions (i.e. headers)
> > but considering feedback is given on this by the community on a voluntary
> > basis, its best to start off the release sooner rather than later to
> > trigger/solicit some proper feedback on this topic otherwise we would be
> > waiting for an extortionate amount of time.
> > * Users of Akka looking to transition to Pekko have raised concerns
> > regarding the release schedule and how long it's taking. While it is true
> > that the release is taking a long amount of time, it should be pointed
> out
> > that this shouldn't be indicative of future releases. In other words, a
> > large reason why the release is taking a long amount of time is that we
> had
> > to deliberate, discuss, plan and actually develop the Apache release
> > process for the first time. Pekko is also a hard fork which is never easy
> > and the current release process is reflecting that.
> > * It was pointed out that the health of the current contributors isn't
> the
> > best (i.e. majority of work is being done by a few people). While there
> are
> > various factors behind this (such as work necessary for first release
> > requires a lot of SBT knowledge, something that only a few people can
> > provide right now) the bigger point to be made here is that its a chicken
> > and egg situation ergo potential contributors are holding back because
> they
> > want confidence in the Pekko project before devoting their time however
> for
> > the project to be more successful we need more contributors for the first
> > release.
> > * We have decided to publish a MILESTONE in the snapshots repository to
> > provide an indication that a release is coming soon. This will occur
> after
> >
> >
> https://github.com/apache/incubator-pekko/pull/270[https://github.com/apache/incubator-pekko/pull/270]
> ,
> > also because
> >
> >
> https://github.com/apache/incubator-pekko/pull/270[https://github.com/apache/incubator-pekko/pull/270]
> > will require downstream
> > changes to every Pekko module (and its easier to refer to a MILESTONE
> > version rather than just git hashes).
> > * Documentation for the rest of the Pekko modules should be published but
> > we shouldn't worry too much about getting the versioning of the docs
> > correct. Having something there is better than nothing, especially
> > considering that documentation is the first thing that users look for.
> >
> > Additional comments are welcome.
> >
> > --
> >
> > 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.dedetrich@aiven.io
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
Re: Plans for Pekko (core) 1.0.0 release
Posted by Michael Seydel <mi...@gmail.com>.
Same as Mehmet, I looked and found that it was non-coding blocking the 1.0
release.
On Wed, May 17, 2023 at 11:34 PM Mehmet Salgar <sa...@gmx.de> wrote:
> >* It was pointed out that the health of the current contributors isn't the
> >best (i.e. majority of work is being done by a few people). While there
> are
> >various factors behind this (such as work necessary for first release
> >requires a lot of SBT knowledge, something that only a few people can
> >provide right now) the bigger point to be made here is that its a chicken
> >and egg situation ergo potential contributors are holding back because
> they
> >want confidence in the Pekko project before devoting their time however
> for
> >the project to be more successful we need more contributors for the first
> >release.
>
> This will sound stupid but a while ago I tried to figure out what I can do
> for Pekko, while I was expecting that somebody would tell me take this
> Issue and fix/implement it, the answer was choose an issue and work with
> it, I looked for three issue s, later to discover other people are working
> on those and then there was some private stuff and I could not be that
> active with contributing.
>
> Now I have more time and am I looking ways to contribute, now is there
> anybody distributing issues or I still have to figure something myself?
>
> Thx for answers...
>
>
>
> Gesendet: Montag, 08. Mai 2023 um 08:37 Uhr
> Von: "Matthew Benedict de Detrich" <ma...@aiven.io.INVALID>
> An: dev@pekko.apache.org, users@pekko.apache.org
> Betreff: Plans for Pekko (core) 1.0.0 release
> Johannes, PJ Fanning and myself had a discussion last week to regarding
> future plans regarding the Pekko 1.0.0 release, below are the generate
> points discussed on this topic
>
> * We should focus on doing a Pekko release first for the core module
> * In terms of actual technical work that needs to be done for a future
> first release, there doesn't appear to be a lot. The last main piece of
> work should be https://github.com/apache/incubator-pekko/pull/281. There
> is
> also Scala 3.3 LTS but considering there is already an open PR for RC4 on
> this (see
> https://github.com/apache/incubator-pekko/pull/270[https://github.com/apache/incubator-pekko/pull/270])
> and RC4 is
> expected to be the last RC before release, this shouldn't be a concern. The
> main thing to look at here is the docker image that Johannes made to help
> in creating a release (see
>
> https://github.com/apache/incubator-pekko/pull/188[https://github.com/apache/incubator-pekko/pull/188]
> )
> * There are still open questions regarding legal questions (i.e. headers)
> but considering feedback is given on this by the community on a voluntary
> basis, its best to start off the release sooner rather than later to
> trigger/solicit some proper feedback on this topic otherwise we would be
> waiting for an extortionate amount of time.
> * Users of Akka looking to transition to Pekko have raised concerns
> regarding the release schedule and how long it's taking. While it is true
> that the release is taking a long amount of time, it should be pointed out
> that this shouldn't be indicative of future releases. In other words, a
> large reason why the release is taking a long amount of time is that we had
> to deliberate, discuss, plan and actually develop the Apache release
> process for the first time. Pekko is also a hard fork which is never easy
> and the current release process is reflecting that.
> * It was pointed out that the health of the current contributors isn't the
> best (i.e. majority of work is being done by a few people). While there are
> various factors behind this (such as work necessary for first release
> requires a lot of SBT knowledge, something that only a few people can
> provide right now) the bigger point to be made here is that its a chicken
> and egg situation ergo potential contributors are holding back because they
> want confidence in the Pekko project before devoting their time however for
> the project to be more successful we need more contributors for the first
> release.
> * We have decided to publish a MILESTONE in the snapshots repository to
> provide an indication that a release is coming soon. This will occur after
>
> https://github.com/apache/incubator-pekko/pull/270[https://github.com/apache/incubator-pekko/pull/270],
> also because
>
> https://github.com/apache/incubator-pekko/pull/270[https://github.com/apache/incubator-pekko/pull/270]
> will require downstream
> changes to every Pekko module (and its easier to refer to a MILESTONE
> version rather than just git hashes).
> * Documentation for the rest of the Pekko modules should be published but
> we shouldn't worry too much about getting the versioning of the docs
> correct. Having something there is better than nothing, especially
> considering that documentation is the first thing that users look for.
>
> Additional comments are welcome.
>
> --
>
> 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.dedetrich@aiven.io
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@pekko.apache.org
>
>
Aw: Plans for Pekko (core) 1.0.0 release
Posted by Mehmet Salgar <sa...@gmx.de>.
>* It was pointed out that the health of the current contributors isn't the
>best (i.e. majority of work is being done by a few people). While there are
>various factors behind this (such as work necessary for first release
>requires a lot of SBT knowledge, something that only a few people can
>provide right now) the bigger point to be made here is that its a chicken
>and egg situation ergo potential contributors are holding back because they
>want confidence in the Pekko project before devoting their time however for
>the project to be more successful we need more contributors for the first
>release.
This will sound stupid but a while ago I tried to figure out what I can do for Pekko, while I was expecting that somebody would tell me take this Issue and fix/implement it, the answer was choose an issue and work with it, I looked for three issue s, later to discover other people are working on those and then there was some private stuff and I could not be that active with contributing.
Now I have more time and am I looking ways to contribute, now is there anybody distributing issues or I still have to figure something myself?
Thx for answers...
Gesendet: Montag, 08. Mai 2023 um 08:37 Uhr
Von: "Matthew Benedict de Detrich" <ma...@aiven.io.INVALID>
An: dev@pekko.apache.org, users@pekko.apache.org
Betreff: Plans for Pekko (core) 1.0.0 release
Johannes, PJ Fanning and myself had a discussion last week to regarding
future plans regarding the Pekko 1.0.0 release, below are the generate
points discussed on this topic
* We should focus on doing a Pekko release first for the core module
* In terms of actual technical work that needs to be done for a future
first release, there doesn't appear to be a lot. The last main piece of
work should be https://github.com/apache/incubator-pekko/pull/281. There is
also Scala 3.3 LTS but considering there is already an open PR for RC4 on
this (see https://github.com/apache/incubator-pekko/pull/270[https://github.com/apache/incubator-pekko/pull/270]) and RC4 is
expected to be the last RC before release, this shouldn't be a concern. The
main thing to look at here is the docker image that Johannes made to help
in creating a release (see
https://github.com/apache/incubator-pekko/pull/188[https://github.com/apache/incubator-pekko/pull/188])
* There are still open questions regarding legal questions (i.e. headers)
but considering feedback is given on this by the community on a voluntary
basis, its best to start off the release sooner rather than later to
trigger/solicit some proper feedback on this topic otherwise we would be
waiting for an extortionate amount of time.
* Users of Akka looking to transition to Pekko have raised concerns
regarding the release schedule and how long it's taking. While it is true
that the release is taking a long amount of time, it should be pointed out
that this shouldn't be indicative of future releases. In other words, a
large reason why the release is taking a long amount of time is that we had
to deliberate, discuss, plan and actually develop the Apache release
process for the first time. Pekko is also a hard fork which is never easy
and the current release process is reflecting that.
* It was pointed out that the health of the current contributors isn't the
best (i.e. majority of work is being done by a few people). While there are
various factors behind this (such as work necessary for first release
requires a lot of SBT knowledge, something that only a few people can
provide right now) the bigger point to be made here is that its a chicken
and egg situation ergo potential contributors are holding back because they
want confidence in the Pekko project before devoting their time however for
the project to be more successful we need more contributors for the first
release.
* We have decided to publish a MILESTONE in the snapshots repository to
provide an indication that a release is coming soon. This will occur after
https://github.com/apache/incubator-pekko/pull/270[https://github.com/apache/incubator-pekko/pull/270], also because
https://github.com/apache/incubator-pekko/pull/270[https://github.com/apache/incubator-pekko/pull/270] will require downstream
changes to every Pekko module (and its easier to refer to a MILESTONE
version rather than just git hashes).
* Documentation for the rest of the Pekko modules should be published but
we shouldn't worry too much about getting the versioning of the docs
correct. Having something there is better than nothing, especially
considering that documentation is the first thing that users look for.
Additional comments are welcome.
--
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.dedetrich@aiven.io
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org