Yes, config packages are better. But I think doing find_package everywhere is better. Assuming you install an SDK for others to use your project. If you're a "product", vendor away. The issue comes when you want to vendor X and Y and both vendor Z independently. Then you're stuck de-vendoring at least one and figuring out how to provide it yourself internally. IMO, better to just let Z make its own install tree and find it as a package from there.

One can write good Find modules, but there is some "taste" involved. I wish we had more good examples to use as templates.

Why exclusive to SWEs? They tend to be more time-restricted than financial-restricted (assuming the "SWE" comes from a job description). I'd be more interested in making sure that those with less well-paying jobs are able to access such benefits rather than stacking it onto those already (probably) making 6-figures.

Of course, the problems arise in the details. Define "volunteer": if $DAYJOB also uses it (in a way related to my role), is it actually, instead, wage theft? Also, quantifying the benefit is a sticky question. Is maintaining 10k emoji packages on NPM equivalent to volunteer work on libcurl? Could it ever be? Is it volunteer work if it ends up with a bug bounty payday? Google's fuzzing grant incentives?

Dad has seen AMC I-6s go 400k before the transmission died and ended its run.

We also need custom runners anyways because macOS and Windows are important and getting those with graphical session access and/or CUDA hardware in the cloud is either $$$$ or severely limited. Even with our setup, we split the build and test phases so that CUDA hardware slots aren't wasted on running compilers. It also lets us test a single build under different environments easily.

So, yeah, I can see fighting with the feature spectrum, but you need to restrict yourself in most other cases with that kind of stuff too. But at least what we do is possible with GitLab-CI.

- clean integration branch histories (series of merge commits) - merge commits can contain metadata (topic-level descriptions, trailers for who reviewed, merge request links, test results, etc.) - you can be (pretty) sure that `git bisect --first-parent` will not run into any compilation problems (logical conflicts occur, but are fairly rare; use merge queues to be sure) - none of the "you merged main into your topic" "backwards merges" to deal with too

Merging and rebasing each have their pros and cons, so why not use the pros of each and mitigate a lot of the cons at the same time.

In this app, I ended up hunting for the first note and by the time I found it, I couldn't remember "how far" up/down the next note was (and by even 3 notes I often lost the direction from 2 to go). I /could/ figure out the key positions and go from the staff, but that goes through the FACE/EGBDF path of what notes the lines on the staff mean and is 100% non-aural for me. It's also extremely slow.

I also have a horrible time finding melodies and rhythms in music (kind of like Steve Martin in The Jerk, just more…physically coordinated at least). I end up "tapping" out every note and lyric syllable instead of being able to tease anything apart (separate instruments help, but then I lose "the rest"). Rarely was I able to effectively utilize those "song tapper" apps in the 00's to find anything I wanted.

I do remember playing the recorder in class in elementary school and at least "Horse With No Name" on a guitar in…some higher grade (7th? 8th?), but I believe those were very physical-oriented finger memory rather than anything to do with my ear helping out. New songs were basically from-scratch practices rather than being able to build on prior experience.

So while my ear might not be "tin", so to speak, my mind is not well-wired for ir.

I ran XMonad for 15 years, but recently switched to river and am loving it.

It also vastly improved battery on my Dell Pro laptop. 58% battery used in 7h45m (light compilation day, but no suspend).

I'm saying that given what details are there, I think the author is closer to "my" end of the spectrum than one where the question makes sense at all.

For me, grouping by app is terrible. Yes, they may all be "Terminal" or "Firefox" windows, but they are for very different things. I'd rather see things grouped by project regardless of "app". But that is what tagging window managers are for :) .

Given that macOS forces that (IMO) braindead tunnel vision paradigm, I think the response should be "Wù".

I wonder if the author is like me in that respect? Not sure I would spend time like this, but I also spent months building my Linux environment from a tty in 2009-2010 (landed on XMonad, finally on River this year after 5 months in GNOME purgatory to force myself to move to Wayland). Last macOS machine I set up, I turned off a bunch of stuff in Settings and was instantly bored because I just didn't want to deal with the window manager at all. It is now my video chat machine because of Dell's "wise" decision to use IPU7 hardware…but I really don't like using it for much else (Asahi reboots are tedious).

What you actually want is a ban on rewriting tags or accepting branch updates to commits that do not have the current commit as an ancestor. These hooks do exist, but are not on by default (beyond the toilet paper protection of needing --force).

You also have to ban deleting branches because otherwise you just delete and push a new one with the same name. Maybe we should store topic branches in repos under refs/topics/ to distinguish integration branches from development/review branches?

Another instance is a build system rewrite. There was a (short) story of the new system itself and then a commit per module on top of that. It landed as 300+ commits in a single PR. And it got rebased 2-3 times a week to try and keep up as more bits were migrated (and new infra added for things other bits needed). Partial landing would have been useless and "rewrite the build system" would have been utter hell for both me developing and anyone that tries to blame across it if it hadn't been split up at least that much.

Basically, as with many things in software development, there are no black-and-white answers here.

FD: I have contributed to git-lfs.