Better document Flogger's status (active, maintained, in use at Google)

[clehene]

Flogger team and users - we love this library.

Flogger has always felt like a hobbyist open-source initiative. However, lately, there's even less activity.
We need to pick our tools and changing a logging API can be painful.

We're curious if:

• this is effectively complete
• is it abandoned
• are there plans to move it to a new home (e.g. CNCF)
• what are other users thinking and alternatives, forks, etc.

[hagbard]

Thanks for the question.

Flogger is maintained, though we've not had time to really work on the open-source docs experience, so I understand why it might appear like there's not much activity.

In terms of features, what's there is stable though there are other features we're either planning or have implemented internally which we hope to get out into open-source at some point (we understand the issues of making breaking changes to a core API like this so we are being ultra-cautious about new features).

For some background, Flogger is what's now used internally in Google for all Java, Kotlin and Android debug logging (which is many millions of log statements), so the existing library/API will continue to work and be maintained for the foreseeable future (and I hope we get time to push out some better docs and new features too). However in Google we don't use Log4J or other backends apart from the default JDK backend, so that's an area in which you might find some issues (but feel free to let us know about that and suggest improvements).

[netdpb]

What @hagbard said. I'm going to close this issue as a housekeeping measure.

[clehene]

@hagbard @netdpb thank you.

This context is useful and, I think, should be part of the README and docs.
Having this used internally at Google is good to set an expectation on whether it's going to be around.

One area that we'd be interesting in understanding is at the integration boundaries and extensibility.
Some examples are with systems such as Google Cloud Logging (e.g. structured logging), Cloud Trace with Open Telemetry, Logback/Log4j.

TBH - It's intriguing that you're using the default JDK backend internally and if there's a path to simplify things, I'd love to understand how JSON logging into Cloud Logging or how it can be tied into tracing.

We need to transition from OpenCensus to Open Telemetry and while at it and while making sure we link logs with traces (https://cloud.google.com/trace/docs/trace-log-integration) can't stop wondering why there's a separate API for logging and tracing and whether something can happen here.

There's likely more to look at in these areas. It'd be good to have a proper venue to share these as well as a path forward to achieve them.

Thanks again for dedicating time to keep this OSS.

[netdpb]

I've edited the summary to refer to the fact that we could document Flogger's status better, and reopened it. Thanks!

[netdpb]

For more discussion of integration boundaries and interaction with things like tracing and cloud logging, I suggest you start a conversation on the mailing list.