Guidelines for river and pingora frontend issues

[drcaramelsyrup]

It'd be nice to have clearer guidelines that indicate the division of responsibilities between river (a pingora "frontend" that compiles into an actual binary) and pingora (the core framework). We've been directing folks' issues to river when it makes sense.

Some classes of features such as no/low-code configuration are already set to belong in river rather than pingora, but other cases may be less clear. For example, some features like Kubernetes ingress implementations per #41 are almost certainly destined for river and not core pingora, but the river implementation may generate a feature request for pingora; the exact division of code might not be clear until design time.

This is a tracking and discussion issue for what those clearer guidelines should be and where to describe them. The ideal outcome is that we minimize confusion and issue redirection between the two projects.

[drcaramelsyrup]

cc @jamesmunns

[jamesmunns]

Thanks @drcaramelsyrup!

I think there's a couple main things to discuss at some point:

1. Making the distinction between "frontends" like River and "the backend" of pingora more clear (and maybe agreeing on where to draw the lines?)
2. Unwinding some code/architectural decisions to make pingora more "friendly" to different frontends
3. Communicating these things up front in the pingora and river repos

WRT 1 + 2: this would be things like removing configuration handling, and maybe things like signal handlers from pingora itself, and instead lean on library APIs and methods that can be used to trigger those actions or provide config.

I'm happy to keep giving feedback as I go, or have a chat/call sometime.

WRT 3: I think once we get on the same page, it'd be good to just write it down in the docs, and link it in both repos. No need for crazy formalism :)