MOZGIII

Seems like I'll be using these quite a lot, and I'm a bit tired of using custom validators.

How about we make the caching calls more explicit? That would mean passing cache impl as an argument to every call/constructor explicitly. I’m not am a fan of magic... To...

I think it's a good idea to have an abstract cache layer, so I'm for it. That said, I need to get up to date with the current cache API,...

What's the point of having a `ChannelVirtualMap`?

Alright, how about we add some guidance on how to report issues in a structured way. For instance: > When creating an issue, specify the crate name in the beginning...

> What would this look like in practice? Right now, we _do_ have docs for the macros under `metrics/src/lib.rs` where we re-export them. Sorry for the delay in the response,...

I'm using `ioctl_*!` macros, and my conversion to `std::io::Error` is `std::io::Error::from(err.as_errno().unwrap())`. This is safe with the current implementation, because it internally uses `nix::Error::result`, that always creates `Error::Sys` variant for `Error`:...

Nice workaround, I'll give it a try later today! Still I'd prefer to have an simpler config for this, as it seems to me like a wide spread approach to...

> You could have the Python script reading that .env file, rather than hardcoding values into the script itself. Yes, I figured. I'd have carry this script around, plus the...

To be more specific, there are numerous issues. 1. `ErrorOverlayEntry.js` imports `react-dev-utils/formatWebpackMessages`, and that, in turn, imports `chalks`. `chalks` then tries to access `process.env.*`, that is not accessible in electron...