Klemens Böswirth

Not sure, the error was a timeout, so I restarted the build, maybe it was just a weird server load issue.

> These default implementation would just throw UnsupportedOperationException and therefore would only have to be overridden if a Java plugin actually supports it. Sounds good. I'm actually not sure, why...

> So then the default implementation of get would handle calling an interface method KeySet getContract() No the idea was that `getContract()` is called separately from the `ProcessProtocol` class at...

> write some decisions so that the API becomes coherent and follows the same principles everywhere. In theory a good idea. But the Java API is already a completely separate...

> Is it for additional methods or for the Plugin interface? Since the `process` plugin (and its protocol) don't allow additional methods, this can only be used for the standard...

All the PRs created by dependabot fail because of the missing line in the release notes. I don't think there is a direct way to tell dependabot to add such...

The disadvantage of this would be that automated dependency updates are not mentioned in the release notes unless we manually add them later. IMO using GitHub Actions in this case...

I'm not sure why dependabot didn't create PRs. Maybe because we didn't have a config file. However, some of the dependencies that are updated in the recent PRs are years...

The point of dependabot is that you don't need to think about your dependencies. It just creates the PR, lets the CI run and then you merge it (or you...

Here's an example of what happens, when dependencies are updated frequently: https://github.com/ElektraInitiative/libelektra/pull/4379#issuecomment-1162449461 dependabot sensibly closes the old PR and opens a new one. But if PRs need manual intervention or...