[GitHub] [incubator-pekko] naosense opened a new pull request, #14: Update github templates

naosense opened a new pull request, #14: URL: https://github.com/apache/incubator-pekko/pull/14 Update some templates for github issues/pr/question Related to #10 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the

Re: [Proposal][Discuss] Create a commits email list

Can we just move all the github notifications to the commits@ mailing list (and maybe rename it to github@ or something)? It seems like most of us prefer to get the notifications directly from GitHub, so I don't think there's much value in splitting them out into separate mailing lists, especially

Re: Pekko-HTTP approach

For clarity, it's my understanding that Johannes was employed by Lightbend until recently. Now I don't know about you guys, but code I write is property of my employer. That's also the reason CCLA's exist. If the case, there wouldn't be any sublicense stuff going on for that work. Anyhow, I don't

Re: [Proposal][Discuss] Create a commits email list

We probably need more mailing lists. If we had an 'issues' list and a 'pullrequests' list then we could keep these emails off the dev list. People could choose to ignore or just dip into the lower priority lists using https://lists.apache.org/ On Fri, 4 Nov 2022 at 19:45, Matthew Benedict de Detr

[GitHub] [incubator-pekko] pjfanning opened a new pull request, #13: remove mima checks

pjfanning opened a new pull request, #13: URL: https://github.com/apache/incubator-pekko/pull/13 * when we change the package names, then the mima binary compatibility checks will fail anyway * we are also likely to start releasing as v1.0.0 meaning that the old Akka version numbers will

Re: [Proposal][Discuss] Create a commits email list

Yeah I am also not sure what value this brings considering that Github pretty much sends you the exact same notifications, I am at the point of putting it into a filter so it goes to ignore. On Fri, Nov 4, 2022 at 7:42 PM Jean-Luc Deprez wrote: > Anybody else feeling a little swamped with the gi

Re: [Proposal][Discuss] Create a commits email list

Anybody else feeling a little swamped with the gitbox notifications still going to dev? Especially because it seems like the goal was to work GH centric, but if you watch in GH + the mailing list, it's a good way to go completely bonkers. I've also attempted to switch to digest for commits list,

[GitHub] [incubator-pekko] mdedetrich commented on issue #11: Renaming the akka package

mdedetrich commented on issue #11: URL: https://github.com/apache/incubator-pekko/issues/11#issuecomment-1303702524 This is indeed correct, the easiest way to resolve this would be to disable the mima package. -- This is an automated message from the Apache Git Service. To respond to the

[GitHub] [incubator-pekko] pjfanning commented on issue #11: Renaming the akka package

pjfanning commented on issue #11: URL: https://github.com/apache/incubator-pekko/issues/11#issuecomment-1303686978 I could be wrong but the mima checks for binary compatibility will likely be meaningless once we change the package names. Maybe we should be pre-emptive and remove the mima ch

Re: findinag and removing the akka name

I'd prefer to get an idea of what's in the main incubator-pekko repo first. Some of the changes we make there will need similar changes in other repos. An example would be the markdown files like README.md and CONTRIBUTING.md - we would probably want to standardise the contributing statement across

findinag and removing the akka name

It might be worthwhile to do a grep across all the repositories and find all the places where "akka" is mentioned. Then we can open a ticket in each project listing all the files that have to be changed. I don't think git has ticket dependencies so we can't open sub tickets directly but we could

[GitHub] [incubator-pekko] pjfanning merged pull request #12: change name of github repo so that workflows run for apache/incubator-pekko

pjfanning merged PR #12: URL: https://github.com/apache/incubator-pekko/pull/12 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@pekko.ap

[GitHub] [incubator-pekko] mdedetrich commented on issue #10: Update templates for pull requests

mdedetrich commented on issue #10: URL: https://github.com/apache/incubator-pekko/issues/10#issuecomment-1303251645 We may want to improve/change the templates later but initially I see no problem in just replacing repo name and urls so its not mentioning Akka or its repos. -- This is an

[GitHub] [incubator-pekko-http] jrudolph opened a new pull request, #2: use scalafmt with same config as proposed for pekko

jrudolph opened a new pull request, #2: URL: https://github.com/apache/incubator-pekko-http/pull/2 This is a preview of what changes would happen if the same config as currently proposed for pekko would be applied here as well. There are still some TODOs left to reformat really everyt

Re: Pekko-HTTP approach

Specifically wrt having the code in pull requests that haven’t been merged yet, I had a discussion with colleagues about this in the past and at least hypothetically speaking since the code is sitting on the branch of the pull request author, if that branch’s main is still based off of Ikea’s AS

Re: Pekko-HTTP approach

> Therefore I’m wondering — is it legal to copy code from PRs that were open before the license change? Are those PRs actually licensed as ASL-2? The ASL2 suggests the answer is yes: > 5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted f

[GitHub] [incubator-pekko] pjfanning merged pull request #9: temporarily remove email action from github builds

pjfanning merged PR #9: URL: https://github.com/apache/incubator-pekko/pull/9 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@pekko.apac

[GitHub] [incubator-pekko] naosense commented on issue #10: Update templates for pull requests

naosense commented on issue #10: URL: https://github.com/apache/incubator-pekko/issues/10#issuecomment-1303192899 This seems easy to me, just replace repo name and urls? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use

[GitHub] [incubator-pekko-http] nvollmar commented on issue #1: Move to upstream parboiled2 dependency

nvollmar commented on issue #1: URL: https://github.com/apache/incubator-pekko-http/issues/1#issuecomment-1303188909 That would make sense -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the spe

[GitHub] [incubator-pekko] jrudolph commented on issue #6: Upgrade scala versions

jrudolph commented on issue #6: URL: https://github.com/apache/incubator-pekko/issues/6#issuecomment-1303186103 On Fri, Nov 4, 2022 at 9:21 AM Alexandru Nedelcu ***@***.***> wrote: > @MateuszKubuszok > > Akka HTTP from what I understand rel

[GitHub] [incubator-pekko-http] jrudolph opened a new issue, #1: Move to upstream parboiled2 dependency

jrudolph opened a new issue, #1: URL: https://github.com/apache/incubator-pekko-http/issues/1 Akka HTTP right now contains a copy of parboiled2 in its sources (with some slight additions). This decision was originally made on the grounds that Akka should not have many dependencies on Scala

Re: Pekko-HTTP approach

IANAL either, but I think the gray area is that some pull requests need to copy parts of existing code or certain aspects of the design of the library. Once you've looked at a library's code and written a PR, there's some risk that you included some content that isn't technically your original work

Re: package names (pekko or org.apache.pekko)

On Fri, Nov 4, 2022 at 9:58 AM Jean-Luc Deprez wrote: > As a commenter in incubator general pointed out, I think there's no rule > stipulating the reverse DNS requirement. If there's no rule, why would > there need te be a request for an exception? I agree, it makes little sense to discuss this i

Re: Pekko-HTTP approach

Maybe more info about the scala-3 branch: Most of it was contributed from external contributors (big shout out to Hugh Simpson and Jan Chyb) with only some parts done by me itself. All the contributions already have gone through PRs to be merged into the scala-3 branch. We kept this long running br

Re: [RESULT] [VOTE] use Github discussions feature

In the thread on lists.apache.org, the subject is `[RESULT] [VOTE] use Github discussions feature`. https://lists.apache.org/thread/oypsnlypqkmorhplf2b45lz8v09t8myr On 2022/11/04 08:14:12 "Claude Warren, Jr" wrote: > PJ, In most of the projects I work on after the vote concludes the results > in

Re: Pekko-HTTP approach

> If Johannes is the author of that PR, it’s a big deal, because he still owns the copyright for his work. This case, as far as I’m concerned, is closed. IANAL but this is my understanding as well. If you yourself create a PR then you retain copyright for it (i.e. the code) which means that its fi

Re: package names (pekko or org.apache.pekko)

I have created a github issue for this as well at https://github.com/apache/incubator-pekko/issues/11. For now I am putting in notes there relevant to the migration (I also mention there that the package name is still yet to be decided). On Thu, Nov 3, 2022 at 10:41 PM PJ Fanning wrote: > Hi eve

[GitHub] [incubator-pekko] mdedetrich opened a new issue, #11: Renamed the akka package

mdedetrich opened a new issue, #11: URL: https://github.com/apache/incubator-pekko/issues/11 We need to rename the package from `akka` to either `pekko` or `org.apache.pekko` (this is still being decided). One thing to note is that this will break some tests, i.e. https://github.com/apache

Re: package names (pekko or org.apache.pekko)

As a commenter in incubator general pointed out, I think there's no rule stipulating the reverse DNS requirement. If there's no rule, why would there need te be a request for an exception? I did find some documentation that states that group ID requirement in the reverse DNS format. But that has n

[GitHub] [incubator-pekko] mdedetrich opened a new issue, #10: Update templates for pull requests

mdedetrich opened a new issue, #10: URL: https://github.com/apache/incubator-pekko/issues/10 We still have the old Akka for templates when issues/pull requests are made (see https://github.com/apache/incubator-pekko/tree/main/.github/ISSUE_TEMPLATE), should remove/replace them as necessary

Re: package names (pekko or org.apache.pekko)

I'm not a committer, but a silent observer and possible user and contributor to other Apache Projects. As such, I would prefer `org.apache.pekko` El vie, 4 nov 2022 a las 9:45, Matthew Benedict de Detrich () escribió: > For me a short package name visually is nicer but I am not going to > strongl

Re: package names (pekko or org.apache.pekko)

For me a short package name visually is nicer but I am not going to strongly push for it especially if it causes problems with Pekko becoming a top level project (and I personally don't have major qualms with org.apache.pekko). I suspect that many of the reasons being presented here (including my o

Re: Pekko-HTTP approach

Lightbend’s CLA doesn’t transfer the copyright, but what it does is it allows Lightbend to “sublicense” it as proprietary, which I guess (IANAL, etc) is why they can legally change the license in their repository without mentioning that some of that code is still available as ASL-2. If Johann

Re: Pekko-HTTP approach

Lightbend’s CLA doesn’t transfer the copyright, but what it does is it allows Lightbend to “sublicense” it as proprietary, which I guess (IANAL, etc) is why they can legally change the license in their repository without mentioning that some of that code is still available as ASL-2. If Johann

Re: package names (pekko or org.apache.pekko)

For a simple library the package doesn't matter all that much. But Pekko is a large framework and typically most of your imports are from that. And you often have to quickly import some implicit extension like the ask pattern, there a short package name is very useful. On Fri, 4 Nov 2022 at 09:23

Re: package names (pekko or org.apache.pekko)

The Apache position is that it is preferred that org.apache be prefixed on Java packages. It is possible to get approval for a shorter pattern but there has to be a good reason. I am not certain that any of the reasons offered so far rise to the level of "a good reason". I don't think this is a

[GitHub] [incubator-pekko] alexandru commented on issue #6: Upgrade scala versions

alexandru commented on issue #6: URL: https://github.com/apache/incubator-pekko/issues/6#issuecomment-1303106514 @nvollmar > Many things like IDE support are still very lacky for Scala 3, but we also don’t gain much by going to the newest Scala version. As long as Pekko supports Scala 2

Re: [RESULT] [VOTE] use Github discussions feature

PJ, In most of the projects I work on after the vote concludes the results in published in an email with "[RESULT]" prepended to the original subject. So for this one it would be: "[RESULT][VOTE] use Github discussions feature" however I think I have also seen it with the "[VOTE]" removed: "[RES

Re: package names (pekko or org.apache.pekko)

If we are talking pros and cons in this thread … I’d like `pekko`:  1. it will make migration from `akka` easier (plain search and replace job, and visually, the code remains the same); 2. the reverse-DNS convention is not common in Scala, at all, and even in the Java and Kotlin ecosystem it’s

Re: package names (pekko or org.apache.pekko)

Pro: pekko Mostly as I prefer less noise in the auto-import popup > On 4. Nov 2022, at 08:27, Jean-Luc Deprez wrote: > > I know my stance is probably known but just to have the arguments in this > thread. > > Pro: pekko > > * Shorter diff and imports, also in consuming code. > * Reverse DNS i

Re: package names (pekko or org.apache.pekko)

I know my stance is probably known but just to have the arguments in this thread. Pro: pekko * Shorter diff and imports, also in consuming code. * Reverse DNS is it bit out of fasion, still makes sense for small projects, but Apache Pekko should sure have the ambition to become thé Pekko of the J