Josh Triplett

@anp This could absolutely be done using the existing concern mechanism and a convention, but the goal here would be to reduce friction and create a more accepted way of...

On Sun, Jul 31, 2022 at 06:03:32PM -0700, Mark Rousskov wrote: > I think with the successor (rustbot) we may be able to arrive at a slightly different model, where...

I'd like this idea, yes. As a more general approach, and perhaps a simpler one, we could also just allow: > @rfcbot delegate @RalfJung Which would give the named user...

I encountered another need for this command today; I'd love to have the ability to let someone else manage a concern on a specific RFC.

"review and approval" seems reasonable, but I agree with @Centril that we want to keep the implication of "review this carefully".

@Byron Catching interrupts won't handle `kill -9`, or a power failure, or similar. You don't have to make entire operations atomic when that isn't possible. It's OK if an interrupted...

> For example, cloning into the same location will have one `git` process fail early as it races to 'creation of .git directory' only, instead of racing for moving the...

It's a CPU-intensive operation; my first instinct would be to run it normally and use unblock or similar to run it on a blocking thread. Trying to structure the computation...

One other thought on that front: compared to the cost of generating a pack, one or two allocations to set up things like channels or Arc will not be an...

https://github.com/zlib-ng/zlib-ng/issues/1279