The changes have been applied, I can confirm that the tags are the same, i.e.
<@incubator-pekko>-<⎇ main>-<*>-> git show-ref --tags 547fb47712724b59eafcde2473cf513c94468bfb refs/tags/forked-from-akka a7da1125b7d3efd3a45af2da7896dee00cb52e8e refs/tags/v0.0.0 e0cff9632736803cb3334b0bb177762e4b7ac851 refs/tags/v1.0.0-RC2 6a639945554e3624aad0070093a41cbcd4ebc416 refs/tags/v1.0.0-rc1 Shows that the old v1.0.0-rc1 points to 6a639945554e3624aad0070093a41cbcd4ebc416 which is what https://github.com/apache/incubator-pekko/releases/tag/v1.0.0-RC1 is pointing to as well. I have also emailed ScalaTimes to update the reference to the git tag uri in their release announcement. The fact that we have external sources/pekko users creating hard links to our git tags already shows that we should be a lot more diligent in these matters, and it's much easier to both fix and familiarize ourselves with the process now rather than later down the road. Also another fun tidbit when trying to fix this, I also realized that git tags on certain platforms are case insensitive (MacOS/Windows) whereas on *nix they are case sensitive which I can easily see creating future potential confusion. On Wed, Jun 28, 2023 at 7:01 PM Matthew Benedict de Detrich < matthew.dedetr...@aiven.io> wrote: > > Can't we just leave it as is? > > I would rather not for reasons stated earlier (in summary making sure git > tags follow standard/correct versioning protocol trumps other concerns). > > > I also stated I would do this over a week ago and no one objected. > > > On Wed, 28 June 2023, 18:49 PJ Fanning, <fannin...@gmail.com> wrote: > >> Changing the existing tag will cause issues too. Emails contain links to >> it. ScalaTimes linked to it in last week's issue. >> >> There is no proven issue with the name of the tag. There is a newer tag on >> the repo for the RC2. >> >> >> Can't we just leave it as is? >> >> On Wed 28 Jun 2023, 16:44 Matthew Benedict de Detrich, >> <matthew.dedetr...@aiven.io.invalid> wrote: >> >> > Just letting everyone know that I have made an INFRA ticket to rename >> the >> > git tag (this needs to be done manually/explicitly since git tags are >> > protected once uploaded), see >> > https://issues.apache.org/jira/browse/INFRA-24739 >> > >> > On Fri, Jun 23, 2023 at 11:02 AM PJ Fanning <fannin...@apache.org> >> wrote: >> > >> > > The vote fail due to Justin McLean's -1 (binding). >> > > >> > > I will remove the artifacts associated with this RC. >> > > >> > > A large number of changes have been made been based on the comments in >> > > this vote. >> > > >> > > Everything since PR 416 has been added since 'rc1' was built >> > > >> > > >> https://github.com/apache/incubator-pekko/pulls?q=is%3Apr+is%3Aclosed >> > > >> > > I might put together an 'RC2' in a few days. >> > > >> > > >> > > On 2023/06/22 11:59:45 PJ Fanning wrote: >> > > > I've raised a GitHub issue [1] for the Play inspired SSL scripts - >> and >> > > > have a PR linked to it. >> > > > >> > > > With the source file headers, the -1 votes are based on cases where >> we >> > > > believe the original Akka code neglected to retain license headers >> > > > from source code that they borrowed from. If anyone finds any >> > > > instances in the Pekko source where they think that we should >> include >> > > > 3rd license headers, please raise an issue in the GitHub issues for >> > > > the repo that the Pekko file exists in. Use the main repo [1] if you >> > > > are not sure which repo to log the issue in. >> > > > >> > > > We are under no obligation to start putting Apache headers on every >> > > > file, especially when we have made little or no modification to it >> > > > [3]. >> > > > >> > > > >> > > > >> > > > [1] https://github.com/apache/incubator-pekko/issues/448 >> > > > [2] https://github.com/apache/incubator-pekko >> > > > [3] https://issues.apache.org/jira/browse/LEGAL-626 >> > > > >> > > > >> > > > On Thu, 22 Jun 2023 at 11:43, PJ Fanning <fannin...@gmail.com> >> wrote: >> > > > > >> > > > > My view on does every file need a license header: >> > > > > * the Pekko community have made no meaningful changes to these >> shell >> > > > > script files, so we don't need to add a Pekko/ASF header >> > > > > * the Lightbend developers chose not to add Lightbend headers so >> we >> > > > > shouldn't add Lightbend headers >> > > > > >> > > > > I don't know what to do about the Play inspired stuff. If anyone >> has >> > > > > any ideas, could they do a PR? >> > > > > >> > > > > On Thu, 22 Jun 2023 at 10:29, Samuele Resca < >> samuele.re...@gmail.com >> > > >> > > wrote: >> > > > > > >> > > > > > Hi, >> > > > > > >> > > > > > I was checking the sources looking for licensing issues. >> > > > > > I spotted the following files without Apache headers: [1] [2] >> [3] >> > > [4] [5]. >> > > > > > Also, worth pointing out that [7], [8], are "inspired by" >> > > playframework >> > > > > > samples (see [6]). That said, the original source is CC0 [9] >> > > > > > >> > > > > > Do we need to take any action here? >> > > > > > >> > > > > > Thanks, >> > > > > > Samuele >> > > > > > >> > > > > > [1] >> > > >> https://github.com/apache/incubator-pekko/blob/main/kubernetes/setup.sh >> > > > > > [2] >> > > > > > >> > > >> > >> https://github.com/apache/incubator-pekko/blob/main/scripts/find_fixed_tickets.sh >> > > > > > [3] >> > > > > > >> > > >> > >> https://github.com/apache/incubator-pekko/blob/main/scripts/git-remove-history.sh >> > > > > > [4] >> > > > > > >> > > >> > >> https://github.com/apache/incubator-pekko/blob/main/scripts/show-serializer.sh >> > > > > > [5] >> > > > > > >> > > >> > >> https://github.com/apache/incubator-pekko/blob/main/scripts/build/github-tagging.sh >> > > > > > [6] >> > > > > > >> > > >> > >> https://github.com/apache/incubator-pekko/blob/main/remote/src/test/resources/ssl/README.md?plain=1#L4 >> > > > > > [7] >> > > > > > >> > > >> > >> https://github.com/apache/incubator-pekko/blob/main/remote/src/test/resources/ssl/genca.sh >> > > > > > [8] >> > > > > > >> > > >> > >> https://github.com/apache/incubator-pekko/blob/main/remote/src/test/resources/ssl/gencerts.sh >> > > > > > [9] >> > https://github.com/playframework/play-samples/blob/2.8.x/LICENSE >> > > > > > >> > > > > > >> > > > > > Il giorno gio 22 giu 2023 alle ore 09:04 Matthew Benedict de >> > Detrich >> > > > > > <matthew.dedetr...@aiven.io.invalid> ha scritto: >> > > > > > >> > > > > > > Yes, it was mentioned in the announcement >> > > > > > > >> > > > > > > > >> > > >> https://repository.apache.org/content/groups/staging/org/apache/pekko/ >> > > > > > > >> > > > > > > > In sbt, you can add this resolver. >> > > > > > > >> > > > > > > > resolvers += "Apache Pekko Staging" at >> > > > > > > "https://repository.apache.org/content/groups/staging"; >> > > > > > > >> > > > > > > On Thu, 22 June 2023, 10:02 Mehmet Salgar, < >> salgar_sw...@gmx.de> >> > > wrote: >> > > > > > > >> > > > > > > > Would be a stupid question but are we publishing the release >> > > candidates >> > > > > > > to >> > > > > > > > any Maven Repository? >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > Gesendet: Dienstag, 20. Juni 2023 um 09:27 Uhr >> > > > > > > > Von: "Matthew Benedict de Detrich" < >> matthew.dedetr...@aiven.io >> > > .INVALID> >> > > > > > > > An: dev@pekko.apache.org >> > > > > > > > Betreff: Re: [VOTE] Release Apache Pekko(incubating) >> 1.0.0-rc1 >> > > > > > > > > 1. Do nothing and leave the files without headers (current >> > > state) >> > > > > > > > 2. Add an Apache header (obviously wrong) >> > > > > > > > >> > > > > > > > Just to clarify, as of currently every single source file >> has >> > an >> > > Apache >> > > > > > > > header. This is a result of the discussions at >> > > > > > > > https://issues.apache.org/jira/browse/LEGAL-626 >> > > > > > > > and is also enforced by sbt-header which ensures the header >> is >> > > forcefully >> > > > > > > > placed on source files. If we shouldn't be placing the >> Apache >> > > header on >> > > > > > > > source files taken from 3rd parties then it should be >> possible >> > > to add a >> > > > > > > > blacklist to sbt-header so it doesn't apply on specific >> source >> > > files. If >> > > > > > > > this isn't possible then we can just disable sbt-header and >> > > figure out >> > > > > > > the >> > > > > > > > issue after a release (we shouldn't be adding new source >> files >> > > now >> > > > > > > anyways >> > > > > > > > since we are in a release period). >> > > > > > > > >> > > > > > > > On Tue, Jun 20, 2023 at 8:07 AM Claude Warren, Jr >> > > > > > > > <claude.war...@aiven.io.invalid> wrote: >> > > > > > > > >> > > > > > > > > There seems to be 3 possible solutions for the missing >> > headers >> > > problem: >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > 1. Do nothing and leave the files without headers (current >> > > state) >> > > > > > > > > 2. Add an Apache header (obviously wrong) >> > > > > > > > > 3. Add a note that indicates where the file is from >> (project, >> > > version, >> > > > > > > > > etc., possibly license info) and that the original file >> had >> > no >> > > header. >> > > > > > > > > >> > > > > > > > > If we do #3 then I think the header should say something >> > like: >> > > > > > > > > >> > > > > > > > > /* This file extracted from <project> <version> <originala >> > > file name> >> > > > > > > > which >> > > > > > > > > was in a package licensed under <license> */ >> > > > > > > > > >> > > > > > > > > Now, I know this technically violates the "don't change >> the >> > > header" >> > > > > > > rule, >> > > > > > > > > however, it is in line with the spirit of the "document >> where >> > > the file >> > > > > > > is >> > > > > > > > > from" rule. >> > > > > > > > > >> > > > > > > > > just my 2 cents, IANAL >> > > > > > > > > Claude >> > > > > > > > > >> > > > > > > > > On Mon, Jun 19, 2023 at 5:19 PM Matthew Benedict de >> Detrich >> > > > > > > > > <matthew.dedetr...@aiven.io.invalid> wrote: >> > > > > > > > > >> > > > > > > > > > > Correct me if I am wrong, but I don't think there is >> ever >> > > a case >> > > > > > > > where >> > > > > > > > > we >> > > > > > > > > > changed an original header. If we did do something >> header >> > > wise, it >> > > > > > > > would >> > > > > > > > > be >> > > > > > > > > > just adding the ASF header above the original. Some of >> > these >> > > cases do >> > > > > > > > > > genuinely seem that Akka/Lightbend forgot to put in >> headers >> > > when they >> > > > > > > > > > should have. >> > > > > > > > > > >> > > > > > > > > > Maybe let me ask this more bluntly, what exactly are we >> > > supposed to >> > > > > > > do >> > > > > > > > in >> > > > > > > > > > this case? There are source files within Akka that was >> > taken >> > > from 3rd >> > > > > > > > > > parties and those files either originally from the 3rd >> > party >> > > or from >> > > > > > > > Akka >> > > > > > > > > > don't have headers. >> > > > > > > > > > >> > > > > > > > > > I don't see what we can do here aside from acknowledging >> > the >> > > code was >> > > > > > > > > taken >> > > > > > > > > > from a 3rd source (which we are doing). Adding any >> header >> > > that is not >> > > > > > > > the >> > > > > > > > > > ASF just seems wrong. >> > > > > > > > > > >> > > > > > > > > > On Mon, Jun 19, 2023 at 5:31 PM Matthew Benedict de >> > Detrich < >> > > > > > > > > > matthew.dedetr...@aiven.io> wrote: >> > > > > > > > > > >> > > > > > > > > > > > This is my suggestion - ask yourself: >> > > > > > > > > > > - Are the copyrights in the header correct? >> > > > > > > > > > > - Have the file changed significantly from their >> > original? >> > > > > > > > > > > - Is the 3rd party code just part of the files or the >> > > entire file? >> > > > > > > > > > > >> > > > > > > > > > > So for [5] I can say the copyright headers seem to be >> > > correct, the >> > > > > > > > file >> > > > > > > > > > is >> > > > > > > > > > > basically unchanged from the original (which is from >> > > Scala/EPFL) >> > > > > > > and >> > > > > > > > > the >> > > > > > > > > > > 3rd party code is for the entire file. >> > > > > > > > > > > >> > > > > > > > > > > [9] is slightly more complicated, the file originally >> had >> > > no header >> > > > > > > > and >> > > > > > > > > > it >> > > > > > > > > > > was copied from >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > >> > >> https://github.com/lagom/online-auction-java/blob/1.4.x/bidding-impl/src/main/java/com/example/auction/bidding/impl/AuctionEntity.java[https://github.com/lagom/online-auction-java/blob/1.4.x/bidding-impl/src/main/java/com/example/auction/bidding/impl/AuctionEntity.java] >> > > > > > > > > > > (as noted in the comment) which is actually from the >> same >> > > company >> > > > > > > > > > > (Lightbend) behind Akka. My assumption here is that >> they >> > > didn't >> > > > > > > > bother >> > > > > > > > > > > putting in a header because it was the same company >> (Akka >> > > and Lagom >> > > > > > > > > both >> > > > > > > > > > > owned by Lightbend). You can make an argument that the >> > > change that >> > > > > > > > Akka >> > > > > > > > > > did >> > > > > > > > > > > to that file is significant in the sense that they >> > > converted the >> > > > > > > > sample >> > > > > > > > > > > code from one type of Actor System untyped to typed >> but >> > > IANAL. In >> > > > > > > > this >> > > > > > > > > > case >> > > > > > > > > > > the entire file is also 3rd party code. >> > > > > > > > > > > >> > > > > > > > > > > > I’d use the original header. >> > > > > > > > > > > >> > > > > > > > > > > Correct me if I am wrong, but I don't think there is >> ever >> > > a case >> > > > > > > > where >> > > > > > > > > we >> > > > > > > > > > > changed an original header. If we did do something >> header >> > > wise, it >> > > > > > > > > would >> > > > > > > > > > be >> > > > > > > > > > > just adding the ASF header above the original. Some of >> > > these cases >> > > > > > > do >> > > > > > > > > > > genuinely seem that Akka/Lightbend forgot to put in >> > > headers when >> > > > > > > they >> > > > > > > > > > > should have. >> > > > > > > > > > > >> > > > > > > > > > > On Mon, Jun 19, 2023 at 5:21 PM Justin Mclean < >> > > > > > > > > jus...@classsoftware.com> >> > > > > > > > > > > wrote: >> > > > > > > > > > > >> > > > > > > > > > >> Hi, >> > > > > > > > > > >> >> > > > > > > > > > >> > [5] to [9] are all files that originated from >> > > non-Lightbend >> > > > > > > > sources >> > > > > > > > > - >> > > > > > > > > > >> > there are issues tracking all these files in the >> Pekko >> > > issues >> > > > > > > > > tracker. >> > > > > > > > > > >> > >> > > > > > > > > > >> > Most of these files were added more than 10 years >> ago. >> > > I'm not >> > > > > > > > sure >> > > > > > > > > > >> > how we are going to improve on the header >> situation. >> > > > > > > > > > >> >> > > > > > > > > > >> This is my suggestion - ask yourself: >> > > > > > > > > > >> - Are the copyrights in the header correct? >> > > > > > > > > > >> - Have the file changed significantly from their >> > original? >> > > > > > > > > > >> - Is the 3rd party code just part of the files or the >> > > entire file? >> > > > > > > > > > >> >> > > > > > > > > > >> If the copywriter are incorrect OR file contents have >> > not >> > > changed >> > > > > > > > > > >> significantly (say more than 1/2 and porting to a new >> > > language or >> > > > > > > > > > >> reformatting isn’t a “change”) and the 3rd party >> code is >> > > the >> > > > > > > > majority >> > > > > > > > > of >> > > > > > > > > > >> the file, I’d use the original header. >> > > > > > > > > > >> >> > > > > > > > > > >> Or another approach might be, keep the header but a >> > > comment in it, >> > > > > > > > > > adding >> > > > > > > > > > >> the 3rd party copyright(s) and license to make it >> clear >> > > that the >> > > > > > > > > > standard >> > > > > > > > > > >> header may not apply to all the code in the file. >> > > > > > > > > > >> >> > > > > > > > > > >> Kind Regards, >> > > > > > > > > > >> Justin >> > > > > > > > > > >> >> > > > > > > > >> > > --------------------------------------------------------------------- >> > > > > > > > > > >> To unsubscribe, e-mail: >> > dev-unsubscr...@pekko.apache.org >> > > > > > > > > > >> For additional commands, e-mail: >> > > dev-h...@pekko.apache.org >> > > > > > > > > > >> >> > > > > > > > > > >> >> > > > > > > > > > > >> > > > > > > > > > > -- >> > > > > > > > > > > >> > > > > > > > > > > Matthew de Detrich >> > > > > > > > > > > >> > > > > > > > > > > *Aiven Deutschland GmbH* >> > > > > > > > > > > >> > > > > > > > > > > Immanuelkirchstraße 26, 10405 Berlin >> > > > > > > > > > > >> > > > > > > > > > > Amtsgericht Charlottenburg, HRB 209739 B >> > > > > > > > > > > >> > > > > > > > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen >> > > > > > > > > > > >> > > > > > > > > > > *m:* +491603708037 >> > > > > > > > > > > >> > > > > > > > > > > *w:* aiven.io *e:* matthew.dedetr...@aiven.io >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > -- >> > > > > > > > > > >> > > > > > > > > > Matthew de Detrich >> > > > > > > > > > >> > > > > > > > > > *Aiven Deutschland GmbH* >> > > > > > > > > > >> > > > > > > > > > Immanuelkirchstraße 26, 10405 Berlin >> > > > > > > > > > >> > > > > > > > > > Amtsgericht Charlottenburg, HRB 209739 B >> > > > > > > > > > >> > > > > > > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen >> > > > > > > > > > >> > > > > > > > > > *m:* +491603708037 >> > > > > > > > > > >> > > > > > > > > > *w:* aiven.io *e:* matthew.dedetr...@aiven.io >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > -- >> > > > > > > > >> > > > > > > > Matthew de Detrich >> > > > > > > > >> > > > > > > > *Aiven Deutschland GmbH* >> > > > > > > > >> > > > > > > > Immanuelkirchstraße 26, 10405 Berlin >> > > > > > > > >> > > > > > > > Amtsgericht Charlottenburg, HRB 209739 B >> > > > > > > > >> > > > > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen >> > > > > > > > >> > > > > > > > *m:* +491603708037 >> > > > > > > > >> > > > > > > > *w:* aiven.io *e:* matthew.dedetr...@aiven.io >> > > > > > > > >> > > > > > > > >> > > --------------------------------------------------------------------- >> > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org >> > > > > > > > For additional commands, e-mail: dev-h...@pekko.apache.org >> > > > > > > > >> > > > > > > > >> > > > > > > >> > > > >> > > > >> --------------------------------------------------------------------- >> > > > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org >> > > > For additional commands, e-mail: dev-h...@pekko.apache.org >> > > > >> > > > >> > > >> > > --------------------------------------------------------------------- >> > > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org >> > > For additional commands, e-mail: dev-h...@pekko.apache.org >> > > >> > > >> > >> > -- >> > >> > Matthew de Detrich >> > >> > *Aiven Deutschland GmbH* >> > >> > Immanuelkirchstraße 26, 10405 Berlin >> > >> > Amtsgericht Charlottenburg, HRB 209739 B >> > >> > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen >> > >> > *m:* +491603708037 >> > >> > *w:* aiven.io *e:* matthew.dedetr...@aiven.io >> > >> > -- Matthew de Detrich *Aiven Deutschland GmbH* Immanuelkirchstraße 26, 10405 Berlin Amtsgericht Charlottenburg, HRB 209739 B Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen *m:* +491603708037 *w:* aiven.io *e:* matthew.dedetr...@aiven.io
