Chris Mason announced that August 28 was his last day at Meta. His Btrfs patch changes his listing to designated reviewer and updates his email. He says David Sterba has handled most maintainership duties for years.
The patch is now visible in a released candidate
Mason's August 27 cover letter says his kernel contributions will continue and describes Meta's commitment as unchanged. These are his statements, not an independently verified staffing guarantee.
The patch replaces his M entry with an R entry and leaves David Sterba listed under M. As checked on September 8, the change is present in Linux 7.3-rc2's MAINTAINERS file. This is an update to the original news: the submitted patch and its inclusion in a tagged tree are separate pieces of evidence.
How to read M, R and L
The file itself documents its notation. M identifies where patches should be mailed, R identifies a designated reviewer who should be copied, and L supplies the relevant mailing list.
Those entries are routing information. They are not an access-control list enforced by Git. Changing a letter does not revoke a person's ability to create a branch, review code or contribute patches. Nor does it guarantee that every invocation of a recipient-discovery script sends anything: a script can suggest addresses, while sending is a separate action.
That matters for a new contributor. Copying only one familiar name from an old article can miss the current review route, even when the technical change is correct.
A reproducible way to find the current contacts
In the kernel source checkout you are actually targeting, first read the subsystem's MAINTAINERS block and any linked submission guidance. Then inspect the recipient suggestions for your patch:
./scripts/get_maintainer.pl path/to/change.patchThis command prints suggestions; it does not email them. Replace the example path with your patch. Review the output against the files changed and the intended target tree. A patch touching both Btrfs and a shared memory-management interface can need reviewers from both areas.
What an operator can infer
The metadata change itself alters no filesystem format, mount option or recovery command. It provides no reason to migrate stored data or alter a running system. Operational decisions should still follow the behavior of the kernel version you deploy and the fixes relevant to your workload.
To assess continuity over time, look for reviewed changes, maintained branches and responses to specific regressions. A current contact entry helps that process; a job-change announcement alone cannot settle the future health of a filesystem.
Check the original patch and Linux 7.3-rc2; explain maintainer metadata without claiming it enforces merge permissions.