> 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, <[email protected]> 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, > <[email protected]> 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 <[email protected]> > 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 <[email protected]> > 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 < > [email protected] > > > > > > 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 > > > > > > <[email protected]> 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, < > [email protected]> > > > 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" < > [email protected] > > > .INVALID> > > > > > > > > An: [email protected] > > > > > > > > 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 > > > > > > > > <[email protected]> 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 > > > > > > > > > <[email protected]> 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 < > > > > > > > > > > [email protected]> 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 < > > > > > > > > > [email protected]> > > > > > > > > > > > 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: > > [email protected] > > > > > > > > > > >> For additional commands, e-mail: > > > [email protected] > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > 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:* [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > 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:* [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > 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:* [email protected] > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [email protected] > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > > > -- > > > > 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:* [email protected] > > >
