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]
