Ashley Mannix

Just coming in through some triage. I think the only outstanding thing here was using our build script to automatically use `track_caller` if we're on at least `1.46.0`.

I think the ordering there could probably be downgraded so long as we always see the store of `STATE` after the store of `LOGGER`. The orderings on initialization are also...

Hi @intgr :wave: This doesn’t sound unreasonable, however I would still argue against another info-like level for this purpose, because the levels are really arbitrary already any changes aren’t necessary...

In general, I would argue against a proliferation of extra log levels in favor of better filtering on other properties of the log event. Levels are at best a coarse-grained...

I think communicating end-user messages is really orthogonal to `log`, which is targeted at collecting diagnostic output. There might be some overlapping technical concerns but the details of end-user rendering...

Thanks for the suggestion @AldaronLau! This sounds like a nice clarification to me.

It's been a long time here. `slog` and `log4rs` have always offered a complete API for building logging pipelines, and libraries like `tracing` have also since come along and scaffolded...

Personally, I think treating errors as first-class concepts in logs is a worthwhile thing to do. It looks like we might not have given this too much thought in the...

We're on board with adding specific support for `std::error::Error` to `log`. There's a PR open at #378 with some initial support that allows you to attach an error to a...

Hey @rimutaka 👋 The blocker for `log`’s stable API is macro support. To fit in with the existing syntax it would probably look something like: ```rust error!(source: e, “Oh no!”);...