Fix put_time() crash on invalid format specifier by TheStormN · Pull Request #4840 · microsoft/STL (original) (raw)

Sorry for the ping, but I see that not only this, but quite few more PRs are waiting for reviews and eventual merge for considerable time. I'm wondering what is the workflow in general? How much time it usually takes and do you have dedicated time for reviewing community supplied PRs?

My apologies for the delay - yes, the backlog has been accumulating. (This is something that I monitor with the STL Status Chart.)

The problem is that I am currently the only STL maintainer able to spend up to 100% of their time on the STL. (See our Maintainer Priorities issue #4700 for weekly updates.) Everyone else is working on high-priority projects like ASAN and even requesting small amounts of their time to review my own PRs is difficult (but necessary as all code must be reviewed by at least one other person, not even I am allowed to check in whatever I want).

I occasionally have non-STL tasks to deal with (ConcRT, ATL/MFC every other quarter). Additionally, I just took a few days off for vacation (my niece's cat-themed 6th birthday party), during which the backlog further accumulated, and as soon as I got back I was slammed with high-priority STL-specific but non-review work - I had to fix a regression on Win11 24H2 (#4844), revert my glorious changes to drop Win7 (#4857), update our LLVM submodule to fix internal "credential scanner" failures (#4862), and fix /analyze warnings for bounds safety (#4856). Today I thought I'd finally have time to get back to reviews, but upon checking the STL-ASan-CI history to record occurrences of sporadic x86 crashes that we missed in #4324 (because I don't get email notifications of STL-ASan-CI failures), I noticed that the x64 tests failed right before I left for vacation. I find sporadic test failures to be absolutely intolerable and in this case I actually knew how to fix them, since in #3922 I had fixed a similar failure with x86 SSE2 instructions and enhanced the ASan machinery to print out unrecognized bytes. So I've spent all day fixing that (and bogus comments) in LLVM ASan, and now validating it with a build. I also have to review an important STL document that my double boss sent to me yesterday.

When the world isn't on fire and I can sit down and review PRs, usually I can dedicate most of my day to it (excluding only meetings and email). The time that it takes to review a PR varies, depending on how complicated the problem and solution are, how familiar I am with the area, how well-structured the PR's commit history and description are, and how much the PR has already been reviewed by other contributors. If the PR is clean and I know the area deeply, I can easily power through a thousand lines in an hour. If the area is complicated, or I notice that something is messed up, a few dozen lines can take longer to either fix or write up what's wrong.

When there are no major distractions, I can usually keep up with or slightly exceed the rate of incoming PRs, which is how we've been able to drain the formerly-numbering-80 PR backlog. But as queueing theory explains, when a source and drain are closely balanced with little excess capacity, any increase in source throughput or reduction in drain throughput causes a massive increase in the backlog (aka why store checkout lines can be massive, etc.).

I'm hoping to make review progress next week, although I can't promise anything. (I try to review high-priority PRs first, but the order in which I review PRs is highly variable - I also like to review easy PRs first, until I'm in the zone and can really focus on complicated changes.)