I was going to suggest something similar - that if we can add new code in new class files - that this simplifies the discussion.
Obviously, this can't always be the answer because if used the wrong way it messes up the public API. The Lightbend headered file could call the new code in the Apache headered file. In some cases, we may still need to make all the changes in the original Lightbend headered file. And in that case, we could add the Apache header after the Lightbend header. On Thu, 17 Nov 2022 at 13:38, He Pin <[email protected]> wrote: > > Can we just add new apache header to newly created files, that's a much > simpler rule to follow? > And what about the akka/stream/impl/fusing/Ops.scala which contains a lots of > akka stream operators? Would It be better that adding new operators to a > dedicated files? > > > On 2022/11/17 12:04:37 Matthew Benedict de Detrich wrote: > > Yeah the issue is more about having to repeat this discussion on every > > single PR due to having to agree upon what is a minor or a major change, > > not about this one specifically. Another thing to keep in mind is that > > evidently people also have different opinions on what is a minor change and > > what is a major. This itself is completely fine and normal, the problem is > > that depending on who is reviewing a certain PR we can get > > different results of what is minor vs major and since we are dealing with > > legal issues here this is not exactly desirable. > > > > This is why I am personally leaning much towards the "lets delegate all > > these header decisions due to minor vs major change at once just before > > release". With such a strategy it's easier to get everyone's opinion from > > the PMCC on the matter, collectively come to some conclusion and then as a > > result of that conclusion we can create more clear rules going forward. > > > > On Thu, Nov 17, 2022 at 12:51 PM PJ Fanning <[email protected]> wrote: > > > > > In https://github.com/apache/incubator-pekko/pull/50 - I'd prefer to add > > > the ASF header to the CopyrightHeader.scala file - after the existing > > > Lightbend header. > > > > > > I think the change is non-trivial. > > > > > > I think this policy would allow us to make some progress. At the moment, > > > the header issue is really jamming up the works. > > > > > > On 2022/11/17 09:21:21 Matthew Benedict de Detrich wrote: > > > > Currently there appears to be confusion and/or disagreement regarding > > > what > > > > constitutes a minor vs major change. For context please have a look at > > > > > > > https://github.com/apache/incubator-pekko/issues/38#issuecomment-1311468140 > > > . > > > > > > > > The main problem I foresee (which arguably in my opinion has already > > > > started) is that due to the definition of minor vs major being quite > > > > subjective, it's already started holding up the progress of doing work > > > > on > > > > Pekko. This has already started with the PR at > > > > https://github.com/apache/incubator-pekko/pull/50 and also at > > > > > > > https://github.com/apache/incubator-pekko-http/pull/8#issuecomment-1316786937 > > > . > > > > In short, if we are going to debate on every single PR what constitutes > > > > a > > > > minor or major change it's going to significantly decrease the velocity > > > of > > > > getting stuff done. > > > > > > > > Would it be possible for us to come to a more technical/strict > > > > definition > > > > on what constitutes a minor or major change? The current disagreement > > > from > > > > the previously mentioned PR's is about whether a change to the build > > > (which > > > > has no effect on the execution/use of the software) is major but there > > > will > > > > undoubtedly be many more cases in the future (i.e. does the package > > > rename > > > > from akka to org.apache.pekko also count as a major change? This one is > > > > a > > > > lot less clear). > > > > > > > > Alternatively is it also possible for us to suspend the changing of > > > source > > > > headers depending on minor/major changes just before we decide to make a > > > > release? This way we can completely eliminate overhead as we work > > > towards a > > > > release and then when a release is ready someone can create a PR with > > > > the > > > > necessary header changes and in that PR itself we can discuss what is > > > minor > > > > and what is major. This can then be tackled at once with increased focus > > > > and efficiency rather than having to do this work on every PR which > > > incurs > > > > a lot of overhead. This is especially appealing if the decision of minor > > > vs > > > > major is going to remain largely subjective. > > > > > > > > Thoughts? > > > > -- > > > > > > > > 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] > > > > > > > > > > -- > > > > 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]
