Klemens Böswirth

@markus2330 Summary of open questions: 1. [Prefix(es)](https://github.com/ElektraInitiative/libelektra/pull/4245#discussion_r953662047): I proposed `elektraX*`, `elektraE*` for `libelektra-operations` and `libelektra-ease`. 3. [Library stability](https://github.com/ElektraInitiative/libelektra/pull/4245#discussion_r935471511): I proposed these rules: > 1. Everything in this repo will be...

> elektra_e_ks would be better That would be a totally different naming scheme than we have right now... > What I could imagine is that the prefix is elektrax, where...

> I think you only need to get used to it. E.g. at the first look, the "elektra" prefixes were also surprising for me. (while writing the code) I think...

@markus2330 ping

AFAICT there are two issues we still disagree on. First the library split and the prefixes used and second the unstable APIs. I'll give answers for both, but I'd prefer...

> Nice trick to reiterate the same argument again and say that nothing should be replied to it To clarify: I had written the response already when I noticed how...

> And each class has it own name prefixes. [...] If we manage that there are not more than a handful classes per library it should work out quite fine....

> Maybe we simply pick another word. E.g. for ksCut: ksOpCut ksDoCut ksRoutineCut ksActionCut IMO only `ksOpCut` is okay here. "routine" and "action" both have to much specific meaning in...

@markus2330 I've moved the library list into the `library_split.md` decision and remove the two extra decisions for the new libraries. I hope this is now satisfactory for you.

Let's not merge this until after #4187 is merged. The changes in `doc/decisions/README.md` will cause another conflict and it's easier and cleaner to rebase this PR after #4187 than to...