provides an excellent example of why commit messages matter. This is more than 1000 lines diff to the build system (and thus potentially very dangerous because of possible supply chain attacks) which has the commit message of
"CI: Update build scripts and Github actions workflow"
Never say what you ware doing (it's obvious this commit is updating build scripts). Say why you are doing it, especially when your commit feels unrelated or at most very tangentially related to the objective of your PR.
> Never say what you ware doing (it's obvious this commit is updating build scripts)
DEFINITELY say what you are doing. And then say why.
This blog post is a good description of the most prevalent convention in how to write good and useful messages (e.g. this is what the Linux Kernel does and given the history of git there's some flow down): https://cbea.ms/git-commit/
The key thing that means you should start with what is having a short one-line summary of what you're doing so you can look at a simple log and see which commit you're interested in.
Small nit: Maybe not say what YOU are doing, but what the COMMIT, when applied, will do. Git is not a personal work log, it's a source code change log. A commit may be a collaborative effort; it may be a squash of a thousand smaller commits; it may be a merge, it may be generated by a tool (like the dependencies), etc.
The commit should summarize what IT does, not what YOU did. In ten years, nobody will care who you are or what you did, but they will care what the code does and why.
> That's the main reason we are using present tense in commit messages, not past tense.
As a linguistic note, commit messages (at least, English commit messages) almost always use an infinitive verb and therefore may be considered to have no tense at all, though to argue that infinitives have no tense you do need to draw a distinction between tense and aspect.
> I believe it’s the imperative (enable widget) not the infinitive (to enable widget)
You're confusing a bare infinitive with an imperative. Infinitives are often, but not always, marked with to. Commit messages are not commands and are not capable of licensing imperative forms.
Here are some examples of bare infinitives in English, with the infinitive form italicized:
1. This organization will help you apply for a loan.
2a. Q: What does he do?
2b. A: Check over the paperwork to be sure everything's right.
A commit message is doing exactly the same thing as occurs in example 2b.
Ironically, the referenced article on how to write good git commit messages (https://cbea.ms/git-commit/) gives no "why" for most of its points. It lists 7 rules, of which 2, 3, 4, 5, 6 are simply declared without rationale.
Not necessarily. It sounds like all of the things mentioned in the commit message are interconnected (updating build scripts and updating gitignore to remove the new build directories). It would be pointless to break these into separate commits, you can't revert just one without reverting the others.
The commit message is lazy, but breaking these into separate commits because of some "also" rule of thumb is just blindly following a rule for the sake of it.
> breaking these into separate commits because of some "also" rule of thumb is just blindly following a rule for the sake of it
Agreed, cargo-culting is always bad!
But, without knowing how OBS development team works, sometimes it does make sense to split commits like this, mainly if you have a larger repository where different people are responsible for different areas in the codebase.
For example, build-scripts sometimes gets managed by other people than the ones writing some core algorithms, who are also different from the people writing public APIs to be consumed by users. In those cases, it makes reviews a lot easier when you can split out to review different commits to different people, instead of having everyone navigate the same commit.
But again, not familiar with the internals nor the development cycle that OBS keeps, so maybe this doesn't make sense in this case.
Yes, makes a lot of sense. Sorry if I gave the impression that I think somehow this PR is wrong or similar. I was just replying to the fact that sometimes splitting up commits makes sense, outside of this PR.
My exception to the "also" rule of thumb is that if the split changes would cover separate areas of the code such that each piece could be easily picked out by "git add -p", then splitting them out isn't required as long as they are all associated to one logical larger story.
> ...you can't revert just one without reverting the others
That's often true in a split out patchset anyway, so I don't think that on its own it stands as a justification for doing things one way or the other.
Dubious. I prefer that style myself, but there's a lot of value in squashing multiple commits around a feature into a single, "this commit implements this feature" commit. Is it valuable to retain the entire development history of a feature, or just the feature itself? What if during the development, it was rewritten a dozen times? What if there's a dozen commits where the author meandered and only in the last three commits got to the point?
Ruthless interactive rebase is one way to fix that last point, but if you take the final result and squash that into a single changeset, there's a point to be made about that as well.
Agreed, it's a matter of preference, but I prefer logically separate changes to be in separate commits at least within the PR, where it may make reviewing the PR easier. It's basic empathy towards the reviewer(s).
Of course, when merged, it often makes sense to squash some commits together, just like you say - long-term, many of the feature development details are not important.
We have a similar template at work, and since we made it the default (on Bitbucket you can pre-fill it), it's saved a ton of back and forth asking questions:
* Description: (What this does, and why)
* Ref: (Ticket/task link)
* To test: (Specific instructions to make sure things are working as expected)
* To deploy: (What specific servers/services to restart, and operations to perform)
Rosetta is incredibly impressive. And I guess it needed to be. The switch to ARM was going to be a hard sell without a fast x86 translation layer. I'm hoping though that devs don't use it as an excuse to never release ARM builds of their software. It would be good to have ARM builds across all the major operating systems.
We have a rule internally that a PR can’t be more than 1,000 loc. I personally find a 1,000 loc PR almost unreviewable. It takes me multiple days and a stack of notes, and still almost always ends up with effects I didn’t anticipate.
Trying to understand the changes and their full implications is nearly impossible. 100 loc is a better top end imho.
Last place I worked (big company, not FAANG) I remember a PR for our main app that affected 500 files and occasionally dozens of places in some of them. All the reviews were "LGTM".
I forget where I first saw it, but there's a joke of "ten lines, ten issues; 1,000 lines, looks good". There's a human limit to how much you can hold in your head when reviewing code.
When you refactor a commonly used structure, it's easily possible to hit situations that you described. In those cases, having nicely organized commits are super important. You need to make sure that the commit that does the refactor only does the refactoring. Nothing else, then you can review the PR commit by commit and it becomes much more manageable.
When people start doing multiple things in a single commit with 1000's of changes, it does become mentally exhausting to review. Unfortunately, it requires either being extremely diligent when making the commits or being familiar with git rebase -i.
Of course, sometimes it's just thousands of lines of new code and impossible to review :).
this is why we have line printers, custom reading tables with balanced soft lighting (print proofing lamps) and more recently, rostrum cameras operated by foot switch.
review with fanfold might be a habit only acquired by formative experience, but once you physically manage the printout, and are comfortably seated with several hundred well spaced lines that aren't directly emitting typically exhausting spikey spectrum light forcing your brain to perform extremely complex colour management to balance your vision, which is the primary factor in concentration depletion in every attempt at testing we've tried over the years, and you mix in modern handwriting recognition and a pico projector display of feedback comments if necessary, I have only witnessed very high productivity. Anyone who is subject to audits will know the satisfaction of dumping fanfold boxes on the auditors desk. Or should.
Question from a naive kiddo; When the PRs are this big, what are the steps taken to "get it in" the master ? Just blindly accept based on CD/CI jobs, or break it down to walk through every change ? "Ref: supply chain attacks"
If I was in the position of having to review that PR, I would probably flat-out reject it and ask for just the minimal changes required.
I don't see how adding an additional capture framework backend would require meaningful changes to the build system.
With some likelihood, in this case, Apple probably won't have the resources to rework their PR and thus the PR will stay un-merged until somebody of the project has time to merge/reimplement the relevant parts.
Which of course is a total shame and I wonder why Apple didn't have "mergeability" in mind when they decided to create their PR. They must have known that "rework the build system" can't be part of a PR adding a capture backend if they wanted any chance of this being merged.
The Apple developer's commit builds upon another pull request which contains the build system work by OBS developers, the build system changes are not part of Apple's commit.
A million comments and this is the only valuable one. Amazing that everyone accepted the premise that Apple proposed refactoring some other project’s CI.
I didn't get where I am today by employing engineers with my profits...
Before three was Dallas, there was The Rise And Fall Of Reginald Perrin, in the main arc a dark parody of 70s corporate England. If you could find a better audio-visual exposition of the transatlantic difference at the end of the nineteen seventies, you will struggle to find a funnier one.
It is not that uncommon to have make changes to a build system in many places in order to support a new architecture. Especially if there was previously only support for a single one.
Just to expand on that, I always say there are three audiences for the commit message:
1. The reviewer
2. Someone scanning commit logs for patches of interest
3. Archaeologists
Archaeologists are people a year, five years, 10 years down the road who are trying to figure out how the code got to be the way that it is, so they can feel confident changing it. (See also "Chesterton's Fence"[1].) Those people should not have to dig out the conversation from some random PR to figure out what's going on.
A fairly common occurrence when looking at old commits is that any URLs mentioned are now 404s, and ticket numbers are for an issue tracker that no longer exists.
Just to chip in what should the commit message say: it should express the intent of the change and the reason of the change (latter could be reference to ticket). I don't think expressing how the intended change is achieved is important, that's what the diff is. If it's not clear in the diff how the intended change is achieved, try adding some comments.
Never say what you ware doing (it's obvious this commit is updating build scripts). Say why you are doing it
Don’t say what you were doing, say what the commit does. A good commit message completes the sentence “when merged this will …”.
Adding a more detailed description on the second line including why things were done is also not bad, but I have a strong opinion that design notes do not belong in the commit log but in code comments or markdown files that are in the repo, so that they can be found more easily and updated.
Note that those commits seem to have been added by an OBS contributor on top of Apple's patch. The fact they touch the entire build system, in a PR that is 100% macOS focused, is much more concerning than the commit messages.
The weird thing to me is that it's not just lower CPU/GPU for OBS, but lower GPU for the game. Maybe just a coincidence, since the CPU fluctuates so much between the two.
Heavily speculating but it's not unreasonable that the recording process impacts the game fps. Eg if you had 2 processes trying to max out your CPU it'd be less efficient than doing them one after the other because they're fighting for resources, doing context switching (losing cache etc).
It's a bit strange to open a pull request from "Developer-Ecosystem-Engineering" instead of an individual account. I wonder if every interaction from this account has to be approved by a board or something.
Don't Apple have a policy that their developers aren't supposed to contribute to Open Source without explicit permission (https://news.ycombinator.com/item?id=22935263)? I imagine this is the result of that policy - if Apple wants to contribute to something as a business there isn't really anyone who would be able to use their individual account to do it without lots of people questioning why that person can when others can't.
Most companies have this policy it’s actually quite important to protect both the company and the project, it wouldn’t surprise me if big projects even mandate it on their side too.
It usually comes in two flavors - individual contribution as you doing something on your own time and equipment and official contributions when the company itself contributes to a project.
This looks to be the latter rather than the former so it would make sense it would come from an Apple account.
> It usually comes in two flavors - individual contribution as you doing something on your own time and equipment and official contributions when the company itself contributes to a project.
My understanding is that Apple's policy is highly unusual in that "individual contribution as you doing something on your own time and equipment" are pretty much not allowed at all.
It’s more complicated than that. Apple’s blanket policy towards such contributions is that anything you do in your own time needs SVP approval, because it might potentially compete with Apple’s business interests. And as a general policy it likes to deny such requests. Other companies have various policies: Google, for example, is for the most part “we’ll let you do whatever but we own the code, and if you want to own it we will make it about as difficult as Apple does”. The whole “you compete with us if you do anything” is a big tech thing, by the way, because they work on so many things that they can scare their engineers with competition threats on any grounds in California. The best that smaller companies can do is restrict you from working on the limited thing they work on, such as developer tooling or a social network.
Meanwhile Microsoft lets their employees do whatever they want after hours, so long as no company provided resources are used.
I know of developers who made quite a bit of $$$ being first out the door with applications utilizing SDKs that they wrote. MS is perfectly happy with their own developers showing off shiny new features.
I am not talking about non-competes, I am talking about moonlighting.
On the day of employee orientation, they specifically talk about moonlighting and HOW to do it.
"Do not use any hardware we provide for you, and do not use any software you installed from the corporate network, buy your own copy of development tools and licenses, you can use the free Azure credits we give you but not the ones linked to your employee login, make sure you use the credits on your personal account."
They do require you not write software that directly competes with existing Microsoft software, for obvious reasons, but other than that it is fair game.
But this doesn't even cover the whole of it. At multiple times, Microsoft has actively encouraged their employees to write software as a side hustle! They've launched internal competitions "We have a cool new SDK, write some software and put it on the MS Store! Best rated software wins some prize!"
The entire "developers first" culture there extends to how they treat their own employees.
Heck MS has a long tradition of employees leaving to start a new company and MS buying that company up a few years later. I suspect that during the 90s/early 2000s it was seen as a good way to innovate, similar to incubator labs within companies now days.
Which law are you referring to? Noncompetes are enforceable in Washington but not in California, for example, and Microsoft has enforced noncompetes for upper management in several high profile cases, but I am not aware of any enforcement against engineers.
And not in california? Its interesting that Apple is seen as hip and cool yet operates a tight leash obviously because it can, legally. Microsoft is... other things... yet is operating a looser leash, albeit also in compliance with law.
> My understanding is that Apple's policy is highly unusual in that "individual contribution as you doing something on your own time and equipment" are pretty much not allowed at all.
I am not sure exactly but I suspect this is employee-specific and may be only for those working on sensitive projects.
I worked at Apple years ago and it was never in my contract or mentioned to me. And there are plenty of more recent developers e.g. Holden Karau who were contributing to open source projects in their spare time whilst working at Apple.
Nope, rather, Apple engineers having side projects is employed-specific and usually requires some sort of special case for them to let you continue working on your thing. This has been a standard part of the contract for a while, and it’s nothing like a decade or two ago where you might have a DTS engineer make a side app or two for fun or give their own, unofficial opinions of the SDK on their personal blog without approval.
At Microsoft at least at my site we are encouraged to contribute to open source and it even brings perks/recognition so really not sure about “most companies” here
We (FAANG) have a list of open source projects that we are not allowed to contribute to without prior permission. Anything else is fair game from what I can tell.
Could be related to the decision to remove individual names from the product about boxes back when Jobs came back to better control leaking of internal information and cut down on poaching. I would think that Apple does not want anyone to know who is working on the screen capture APIs as this PR would probably come from one member of that group
"When Steve came back, one of his company-wide edicts was that the names of individuals must be removed from about boxes."
Is that rare? I would have thought many FAAG employees contribute to open source projects relevant to them as part of their work. After all that seems like the easiest way to influence the projects.
There's a good post on HN about what it cos Apple to make OS X a certified UNIX. Due to the secrecy of the project they had to use non-corporate accounts for committing bug fixes. The amount of changes was pretty big, but nobody excepts the authors can say it came from Apple.
Of course they will commit to open source projects if it suits their needs (if they use those projects). But people have different opinion on what Apple's needs are.
There's a pretty big distinction between FAANG employees contributing on their own time to things tangentially related too their job, and FAANG employees contributing on behalf of the company (i.e. being paid to do so as an official part of their day job).
Judging by the Engineering account being used to submit this patch, this is likely to be an example of the latter.
In that case, no, almost no FAANG employees do that. I would have had to file paperwork and receive legal signoff for each individual patch to any open-source projects that weren't owned by the company.
What does exist is specially "blessed" FAANG teams who are cleared to contribute to specific open-source projects that are critical to the business. Amazon has a team who contributes to the linux kernel for hypervisor support, for example.
TBF I don’t know how much “we want $popular project to take advantage of our platform” is to be celebrated.
It’s better than bitching about bad support without doing anything. But at the most fundamental of levels it’s really the company working for their customers, through a third party’s project.
I think situations where literally all parties involved are better off than they were before should be celebrated, even if the intentions behind it aren't just philanthropic.
Why would Apple be supposed to do this? Without any other argument on the table, taking that statement to its logical conclusion, it would imply Apple is supposed to help make every single project run well on their hardware.
Even when restricting that to “open source projects that (cl)aim to run on latest MacOS”, I think that’s not something a vendor is “supposed to do”.
So, if Apple only “is supposed to” support some projects, what objective criteria should it use to pick them?
I think it’s completely fine if Apple wouldn’t support any open source. I also think it’s completely fine if developers would choose not to write software for their OS because of that.
HP tried to do something similar when working with openstack. It was done for very bureaucratic reasons / company visibility. (Author was preserved, commit was by something like the-project-name@hp.com) A slightly misguided idea by people who don't normally work with big open source. It was reverted since it messed with project statistics.
From experience in a big company (not Apple) likely direct manager then senior manager then legal department. The justification and hoop jumping would take much more effort than the coding.
I am aware of several projects that Apple has existing relationships with that have streamlined processes, but to my understanding the “ask a SVP” remains the standard policy for getting permission to contribute to an open source project.
It is not. You only need the SVP permission if you are doing larger contributions and frequently. Smaller contributions or one offs don't go up the chain as far, and can just require manager+legal approval
Well, given the amount of publicity this PR is getting it probably makes sense to not just let a random software engineer post whatever they feel like.
For those of you who have contributed to a Github (or similar) project in your capacity as an employee, do you use a work account separate from your own?
It's actually some of the best software I've used for streaming. Also, the feature to record a browser tab is a life saver when I'm double booked and don't want to miss content from a meeting.
< The __MAC_10_15 define may not exist on devices running < 10.15, resulting in this section not being appropriately avoided during compilation. Swapping to 101500 should work for all versions of macOS.
So they are mindful of people with old Macs. This is good!
I find this PR an interesting opportunity to discuss different types of documentation.
I've internalized that there's a difference between the PR description, commit messages, and code comments. For me there's different intended audiences for all three, and their contents should thus be shaped accordingly. This PR basically combines all three into one and uses that as the commit message, and I'm not sure of what to make of it. Is this good practice?
Personally I find the contents of the "#### Summary of Changes" list to be super-neat and helpful. But should these not be more helpful as comments inside the code? On the other hand, it does explain what the code is doing at this snapshot in time: which makes it more precise than comments in the code -- since future changes might eventually make those comments incorrect.
> On the other hand, it does explain what the code is doing at this snapshot in time: which makes it more precise than comments in the code -- since future changes might eventually make those comments incorrect.
If changes are made to the code, the comments should be updated accordingly. Getting from code to a PR text is a non-obvious and difficult process and when parts of the code are updated, the trail is easily lost.
Personally I like for the dev to do little commits that document each change to a file and then when the branch is merged in you do a squash merge and each commit msg becomes a bullet point.
I realize this is specific to having an interface that makes it easy, but I find it valuable to step through each commit in a larger merge review. I'm not a fan of how e.g. bitbucket doesn't make it easy to browse the commit contents .
Now I hope they improve the situation of virtual cameras. Now you need to code sign all kinds of applications in order for them to recognize your applications, which often breaks those applications.
If anyone watches "Meet Kevin" youtube channel, you would know the bad publicity Apple gets with him attempting to stream on his relatively new Mac Pro system. Any effort to improve that capability would be in Apple's best interest. Streaming is not going away.
I want to know if they’re using Rosetta on their M1 test machine or running it natively. Hopefully this patch leads to a proper darwin/arm64 release so I don’t have to use this weird fork[0] with a private GitHub Action to get a native build. The Rosetta version is considerably slower.
> I want to know if they’re using Rosetta on their M1 test machine or running it natively
Natively.
There's an open PR[0], #5155, to get OBS native on Apple Silicon. That's also what your weird fork uses.
Apple's PR is on top of that work: you'll see that there are 10 or so initial commits. Thus #5155 will need to be merged first, before Apple's.
#5155 is a huge PR and has been open for 5 months. Its release will also necessitate OBS get an M1 testing solution figured out. Here's a quote[2] from an OBS team member two days ago:
> [This PR is] top of our priority list once we release 27.2. We're keenly aware of how badly people want a native Apple Silicon build, and I can assure you that we will definitely be publishing official test builds of OBS with M1 support as soon as we are able.
I would nevertheless expect for all of this to take quite a while.
I wonder if this will provide a way to hide the yellow dot that appears in the corner (to indicate mic access). It is a great idea in most cases, but quite annoying to see on screen recordings.
Maybe OBS will work on my Mac now. I struggled to get it working, everything recording as I wanted. Thought it was just "crappy open source" stuff, so gave up.
Some time later, I tried OBS on Windows, and it just worked, first time, no fiddling required. And I realised the problem was on the Mac side, not Obs.
Between one and two years ago, my team had serious issues getting OBS working reliably on T2-equipped Macs. We switched to an expensive commercial product and all our problems went away.
I couldn't duplicate the OBS issues on older Macs that didn't have the T2 chip.
In the PR description, if you expand the sections "Baldur’s Gate 3 Demo", "Shadow of the Tomb Raider", etc. it shows the performance improvement of capturing the respective games. Looks like a very significant improvement.
Should this allow OBS to not capture the actual OBS window itself? I'd think it would be nice to eliminate that from what is captured, for those poor people who only have a single monitor. :)
How does one go about reviewing such a PR? If the PR consists of smaller commits then it would probably be easier. But if a large commit is made, then what would be the flow to review it?
ScreenCaptureKit seems to Apple only, so this only helps Mac users.
While nice it seems to be a trend where Apple seems to contribute to open source projects now to improve its own performance only on their own devices (blender comes to mind). Maybe Im being a bit cynical.
I mean, it's not a bad engineering philosophy for things as low-level as this to be provided by the OS as a framework. Capturing screen output at a high refresh rate without introducing lag may be better implemented with lower-level access to certain system components, in a way that may require certain privileges in order to make it work.
You can provide a nice higher-level API (like ScreenCaptureKit) to access such "privileged" capabilities from normal apps, so that arbitrary open-source software (like OBS) can hook into it.
It seems like Apple already made ScreenCaptureKit for their platforms, and wanted to help OBS by hooking it up to ScreenCaptureKit to take advantage of that work.
The alternative, which is to do all the private/privileged stuff directly in OBS, means that Apple would have to give the general ability for arbitrary software to do what ScreenCaptureKit is doing, which may be a security issue (spyware that snoops on what's being displayed on screen comes to mind.) Making something like ScreenCaptureKit as the supported interface to do this kind of thing, can ensure the app triggers the proper permissions dialog/etc so that screen recording doesn't happen without user knowledge.
The point of open source (not just a free binary blob) is that you can fix the parts that matter to you.
In the case of companies, they typically work on the parts that matter to them. This has been true since the free software movement started to reach into businesses, with companies like Cygnus (of course) but also Sun, SGI, IBM etc all working just on their own platforms.
That’s a fair point. I haven’t looked at their contributions, but it would be nice if they’d help out the project as a whole as well.
I also got a Linux preinstalled conputer, so I’m hoping (selfishly perhaps) that open source projects have great first rate open source OS support. It seems like open source is always resource strapped.
But you are right it’s not like IBM, SGI, Sun weren’t proprietary..
NeXT funded and performed quite a bit of open source software, quite a bit of which continued in the Apple transition.
Make no mistake: for all of these companies, this funding was in support of their commercial activities. They have no desire, say, to write a shell so if one is popular they'll go that way. One thing we taught then in the 90s was that stepping off the mainline simply added to your support cost; this lesson is why so many proprietary companies do contribute back.
Apple's case is interesting: they think more deeply than many about this. Thus they are enthusiastic about standards when they are weak in the domain: e.g. Apple was explicit up to the Jobs level that they embraced open standards like JPEG and MP3 when trying to dig the Mac out of a deep hole; once they had a solid foothold they felt comfortable trying out proprietary formats. They went USB-C (and handed over a majority of the work on its design to the USB consortium, or so a couple of friends who worked on the standard claimed to me) because it helps adoption of the Mac and iPad; but aren't afraid to make a MagSafe connector.
It's all about strength and weakness to Apple, an approach which frankly more companies should adopt (looking at you MediaTek, AllWinner and your competitors).
If Apple, Intel, AMD, NVIDIA, Arm, Qualcomm, etc. would all contribute to open source to make everything work on all their devices with good perf, then that would be very good for all users.
Expecting AMD to make open source contributions to improve software on Apple's hardware or Arm GPUs is "naive", not cynical.
It would be like expecting Tesla to go to VW and help them improve their combustion engines for free.
Apple should be ashamed. Microsoft does so much for open source (VS code, typescript, .NET, Blazor and dozens other projects) and even Goolge does quite a lot. And only $Apple$ is an ego-driven company that only cares how to squeeze as much money as possible from customers.
The message for the PR (under the Conversation tab) justifies this as:
> plugins/mac-capture/mac-display-capture.m:621 - The __MAC_10_15 define may not exist on devices running < 10.15, resulting in this section not being appropriately avoided during compilation. Swapping to 101500 should work for all versions of macOS.
That’s just adding another layer of abstraction over exactly what the Mac case does. I prefer code that is so simple it doesn’t need to be abstract, as every abstraction layer is a potential bug layer.
> That’s just adding another layer of abstraction over exactly what the Mac case does. I prefer code that is so simple it doesn’t need to be abstract, as every abstraction layer is a potential bug layer.
I'm happy for you if you never typed 10150 or 01150 instead of 101500 or whatever but that's definitely not my case and I need any tool that the programming language provides to help me with that ; version macros are unambiguous and I don't remember fucking one up.
Surely you see the contradiction in the system you describe as `terrible` being the exact same as the system you call `good`? In either case, macros are available in modern versions but attempting to use them in old versions causes problems (see the links above), so the practice is to not use them at all, if you may have to target older versions.
> Surely you see the contradiction in the system you describe as `terrible` being the exact same as the system you call `good`?
how is it the exact same ? Where is the generic MACOS_VERSION(sane, version, numbers) where MACOS_VERSION(11, 3, 0) also compiles on the macos 10.7 SDK ?
Windows Version check would disagree with you why this abstraction is required. I forgot the api but there is kernel api that will contradict with your view points.
https://github.com/obsproject/obs-studio/pull/5875/commits/8...
provides an excellent example of why commit messages matter. This is more than 1000 lines diff to the build system (and thus potentially very dangerous because of possible supply chain attacks) which has the commit message of
"CI: Update build scripts and Github actions workflow"
Never say what you ware doing (it's obvious this commit is updating build scripts). Say why you are doing it, especially when your commit feels unrelated or at most very tangentially related to the objective of your PR.