zah

Better article on rough consensus: https://doist.com/blog/decision-making-flat-organization/

I've outlined how the cache is going to work. I don't see any problem with binary packages used in nimble-initiated builds. Nimble will select the correct package path derived from...

And as long as we are listing non-critical deficiencies, there are many for submodules/makefiles as well: * More difficulty when testing the effect of a library change in both beacon_node...

It seems to me that Hive could be a valuable addition to the environment I'm describing, but the relation is that the environment contains Hive and other debugging tools instead...

I'll rework the example once the new hot-reloading APIs have landed. We'll ship the required Nim browsersync server as a npm package.

BrowserSync is a more feature-rich system. It has some additional capabilities such as synchronizing the scrolling and clicking behavior across all devices that have opened the page (in other words,...

> we'll want a "slow" transition from nbs to nimble, gradually replacing its functionality (cross-compiling, integration with complex C libraries like libbacktrace and build systems like autoconf/cmake etc) and these...

> eventually, we'll probably want to see if there is any way to get rid of it, but that requires redesigning nim and nimble to work better together without the...

The proposed ideas bring only minor benefits IMO. You make nimble incompatible with older versions of Nim, just so you can stop using `nims` files (which shouldn't be considered a...

One of the ideas we had for nim-metrics is to support compile-time configuration specifying which metrics are enabled/disabled. The idea is that a library like libp2p should never face the...