Tobias Ribizel

Agreed, to me the more contentious part of this design lies in the mapping from parsed config to generated object though. If we have a JSON `object` as the top-level...

To me the question is: Do we need a user-accessible format-agnostic representation of the structure? If not, we can have a parse_json and parse_yaml function that only require an istream/string...

I don't think avoiding deprecation warnings is a good idea. They are there explicitly to tell users that they are using functionality that will go away in the future, so...

That is not our responsibility. If people want to support a wide range of versions, they need to take care of switching between different interfaces themselves, like we do with...

We never delete interfaces between minor releases, so they can use the version number to decide which code to use. `develop` itself cannot be stable, otherwise we would be regularly...

`develop` is a moving target, so people need to always build ginkgo from the latest state if they want to rely on it. We always update the version number after...

Thanks for kicking off this discussion, I think our separation into core and device is a strong suit of our project that we should make sure to keep up. There...

We had three small bugs that need to be fixed, and I'll try to reduce the test runtime, but otherwise it's ready, yes

I fully agree with merging build and test jobs, and if we use a full compute node, the builds also become blazingly fast :sparkles: That also saves us the complexity...

IMO we should be aiming to make our pipelines more uniform so they work across different gitlab runner executors and hardware platforms. My current plans for the CI setup goes...