Keeping The Torch Burning
Merged This Week
Opened This Week
- short-ice, which should be pretty much ready to wrap up and ship.
- link-args-order, ls-metadata and lto-readonly-lib, which has a very strange error where it crushes the entire wall of text that is
stderr
into nothing else but a single double-quote"
. - compiler-lookup-paths, dump-mono-stats and prune-link-args, which makes me run into the exact same issue the test author did 11 years ago - the ui test directory not understanding what a double-quote is.
Still Open
- pgo-branch-weights, which has now been open for 25 days. At least, with this big rebase on top of the new API, maybe something will actually happen for once.
- nm implementation, which has been completely reworked to use the
object
crate instead... and is now crushing me under a truckload of lifetime errors. There must be a better way to do this. - fs wrappers, which only need to wait for the intimidatingly-named drop bombs to exit the merge queue.
- symlinked-extern, symlinked-rlib and symlinked-libraries, which simply needs fs wrappers merged before it can proceed.
- link-arg, link-dedup and clear-error-blank-output, which hilariously previously failed because the final test was previously named
no-panic-blank-output
, and it includesoutput.assert_stderr_not_contains("panic")
, which was tripped by the name of the test. Right now, the test is failing because I am fighting the borrow checker for the last 2 statements:
out.assert_stdout_contains("lfoo");
out.assert_stdout_contains("lbar");
And it feels wrong to just derive(Clone)
and call it a day.
The set of PRs merged and open this week is less bountiful this time - yes, I spent a lot of time debugging and patching some of the cursed tests clogging up the queue, but there has also been some interesting discussions and progress on improvements to run_make_support
: tightening up the various utilities like rustc
so their output must be handled, and making said output be much more controlled with designated functions to process stdout
and stderr
.
I've noticed that there's been some interest from experienced contributors in helping out the run-make-support
efforts. In a way, I am glad - it shows that maintainers think this project has value and that it's not some "intern oubliette" where you assign beginners to an insignificant part of the codebase and breathe a sigh of relief as you realize there is no way they will break anything important.
But, it also makes it really motivating to do more, seeing all these metaphorical pickaxes striking the rock in unison, and mine not being as used as it could be. Don't get me wrong, the team seems happy with my progress thus far - a sustainable pace to match the extended 18 weeks duration - but had I not balanced this commitment with a full time internship, there could have been a little more pep to it.
Example: other Summer of Code contributors are relentlessly posting about what they do on their side in the Zulip thread, and I harbour some curiosity to understand more what they are doing - as just reading the words quickly without research is roughly equivalent to reading ancient Babylonian scripture. But, I am so drenched in technology weekly that it wouldn't be a good idea. I could, but I'm doing everything to keep the torch burning and try not to go to too many "extra miles" until I fall off the cliff.
My fear was making the foolish choice of mediocrity in two commitments over excellence in one. And, it doesn't seem like that is currently happening, but it is nonetheless worrying.
Once this summer passes, I will definitely be thinking things over more in the future when it comes to opportunities. Life isn't some RPG where you can have 12 active quests at the same time. I wonder how the highest octane maintainers do it, since they might be even busier than I am.