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]> > 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] > >
