diff --git a/MAINTAINERS b/MAINTAINERS
deleted file mode 100644
index 0e0100e..0000000
--- a/MAINTAINERS
+++ /dev/null
@@ -1,47 +0,0 @@
-How to use this list:
-    Find the most specific section entry (described below) that matches where
-    your change lives and add the reviewers (R) and maintainers (M) as
-    reviewers. You can use the same method to track down who knows a particular
-    code base best.
-
-    Your change/query may span multiple entries; that is okay.
-
-    If you do not find an entry that describes your request at all, someone
-    forgot to update this list; please at least file an issue or send an email
-    to a maintainer, but preferably you should just update this document.
-
-Description of section entries:
-
-    Section entries are structured according to the following scheme:
-
-    X:  NAME <EMAIL_USERNAME@DOMAIN> <DISCORD_USERNAME!>
-    X:  ...
-    .
-    .
-    .
-
-    Where REPO_NAME is the name of the repository within the OpenBMC GitHub
-    organization; FILE_PATH is a file path within the repository, possibly with
-    wildcards; X is a tag of one of the following types:
-
-    M:  Denotes maintainer; has fields NAME <EMAIL_USERNAME@DOMAIN> <DISCORD_USERNAME!>;
-        if omitted from an entry, assume one of the maintainers from the
-        MAINTAINERS entry.
-    R:  Denotes reviewer; has fields NAME <EMAIL_USERNAME@DOMAIN> <DISCORD_USERNAME!>;
-        these people are to be added as reviewers for a change matching the repo
-        path.
-    F:  Denotes forked from an external repository; has fields URL.
-
-    Line comments are to be denoted "# SOME COMMENT" (typical shell style
-    comment); it is important to follow the correct syntax and semantics as we
-    may want to use automated tools with this file in the future.
-
-    A change cannot be added to an OpenBMC repository without a MAINTAINER's
-    approval; thus, a MAINTAINER should always be listed as a reviewer.
-
-START OF MAINTAINERS LIST
--------------------------
-
-M:  Brad Bishop <bradleyb@fuzziesquirrel.com> <radsquirrel!>
-R:  Brad Bishop <bradleyb@fuzziesquirrel.com> <radsquirrel!>
-R:  Andrew Geissler <geissonator@yahoo.com> <geissonator!>
diff --git a/meta-amd/MAINTAINERS b/meta-amd/MAINTAINERS
deleted file mode 100644
index a46f429..0000000
--- a/meta-amd/MAINTAINERS
+++ /dev/null
@@ -1,45 +0,0 @@
-How to use this list:
-    Find the most specific section entry (described below) that matches where
-    your change lives and add the reviewers (R) and maintainers (M) as
-    reviewers. You can use the same method to track down who knows a particular
-    code base best.
-
-    Your change/query may span multiple entries; that is okay.
-
-    If you do not find an entry that describes your request at all, someone
-    forgot to update this list; please at least file an issue or send an email
-    to a maintainer, but preferably you should just update this document.
-
-Description of section entries:
-
-    Section entries are structured according to the following scheme:
-
-    X:  NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>
-    X:  ...
-    .
-    .
-    .
-
-    Where REPO_NAME is the name of the repository within the OpenBMC GitHub
-    organization; FILE_PATH is a file path within the repository, possibly with
-    wildcards; X is a tag of one of the following types:
-
-    M:  Denotes maintainer; has fields NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>;
-        if omitted from an entry, assume one of the maintainers from the
-        MAINTAINERS entry.
-    R:  Denotes reviewer; has fields NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>;
-        these people are to be added as reviewers for a change matching the repo
-        path.
-    F:  Denotes forked from an external repository; has fields URL.
-
-    Line comments are to be denoted "# SOME COMMENT" (typical shell style
-    comment); it is important to follow the correct syntax and semantics as we
-    may want to use automated tools with this file in the future.
-
-    A change cannot be added to an OpenBMC repository without a MAINTAINER's
-    approval; thus, a MAINTAINER should always be listed as a reviewer.
-
-START OF MAINTAINERS LIST
--------------------------
-
-M:  Supreeth Venkatesh <supreeth.venkatesh@amd.com>
diff --git a/meta-ampere/MAINTAINERS b/meta-ampere/MAINTAINERS
deleted file mode 100644
index 7b44e58..0000000
--- a/meta-ampere/MAINTAINERS
+++ /dev/null
@@ -1,49 +0,0 @@
-How to use this list:
-    Find the most specific section entry (described below) that matches where
-    your change lives and add the reviewers (R) and maintainers (M) as
-    reviewers. You can use the same method to track down who knows a particular
-    code base best.
-
-    Your change/query may span multiple entries; that is okay.
-
-    If you do not find an entry that describes your request at all, someone
-    forgot to update this list; please at least file an issue or send an email
-    to a maintainer, but preferably you should just update this document.
-
-Description of section entries:
-
-    Section entries are structured according to the following scheme:
-
-    X:  NAME <EMAIL_USERNAME@DOMAIN> <DISCORD_USERNAME!>
-    X:  ...
-    .
-    .
-    .
-
-    Where REPO_NAME is the name of the repository within the OpenBMC GitHub
-    organization; FILE_PATH is a file path within the repository, possibly with
-    wildcards; X is a tag of one of the following types:
-
-    M:  Denotes maintainer; has fields NAME <EMAIL_USERNAME@DOMAIN> <DISCORD_USERNAME!>;
-        if omitted from an entry, assume one of the maintainers from the
-        MAINTAINERS entry.
-    R:  Denotes reviewer; has fields NAME <EMAIL_USERNAME@DOMAIN> <DISCORD_USERNAME!>;
-        these people are to be added as reviewers for a change matching the repo
-        path.
-    F:  Denotes forked from an external repository; has fields URL.
-
-    Line comments are to be denoted "# SOME COMMENT" (typical shell style
-    comment); it is important to follow the correct syntax and semantics as we
-    may want to use automated tools with this file in the future.
-
-    A change cannot be added to an OpenBMC repository without a MAINTAINER's
-    approval; thus, a MAINTAINER should always be listed as a reviewer.
-
-START OF MAINTAINERS LIST
--------------------------
-
-M:  Thang Q. Nguyen <thang@os.amperecomputing.com> <thangqn!>
-M:  Tung Nguyen <tungnguyen@os.amperecomputing.com> <tungnguyen-ampere!>
-R:  Phong Vo <phong@os.amperecomputing.com>
-R:  Quan Nguyen <quan@os.amperecomputing.com>
-
diff --git a/meta-aspeed/MAINTAINERS b/meta-aspeed/MAINTAINERS
deleted file mode 100644
index f1f736f..0000000
--- a/meta-aspeed/MAINTAINERS
+++ /dev/null
@@ -1,49 +0,0 @@
-How to use this list:
-    Find the most specific section entry (described below) that matches where
-    your change lives and add the reviewers (R) and maintainers (M) as
-    reviewers. You can use the same method to track down who knows a particular
-    code base best.
-
-    Your change/query may span multiple entries; that is okay.
-
-    If you do not find an entry that describes your request at all, someone
-    forgot to update this list; please at least file an issue or send an email
-    to a maintainer, but preferably you should just update this document.
-
-Description of section entries:
-
-    Section entries are structured according to the following scheme:
-
-    X:  NAME <EMAIL_USERNAME@DOMAIN> <DISCORD_USERNAME!>
-    X:  ...
-    .
-    .
-    .
-
-    Where REPO_NAME is the name of the repository within the OpenBMC GitHub
-    organization; FILE_PATH is a file path within the repository, possibly with
-    wildcards; X is a tag of one of the following types:
-
-    M:  Denotes maintainer; has fields NAME <EMAIL_USERNAME@DOMAIN> <DISCORD_USERNAME!>;
-        if omitted from an entry, assume one of the maintainers from the
-        MAINTAINERS entry.
-    R:  Denotes reviewer; has fields NAME <EMAIL_USERNAME@DOMAIN> <DISCORD_USERNAME!>;
-        these people are to be added as reviewers for a change matching the repo
-        path.
-    F:  Denotes forked from an external repository; has fields URL.
-
-    Line comments are to be denoted "# SOME COMMENT" (typical shell style
-    comment); it is important to follow the correct syntax and semantics as we
-    may want to use automated tools with this file in the future.
-
-    A change cannot be added to an OpenBMC repository without a MAINTAINER's
-    approval; thus, a MAINTAINER should always be listed as a reviewer.
-
-START OF MAINTAINERS LIST
--------------------------
-
-# THIS REPOSITORY HAS A DIFFERENT SUBMISSION PROCESS: this is a subtree in
-# @openbmc and is synced by the maintainer using git-subtree. Please submit
-# changes against @openbmc.
-M:  Brad Bishop <bradleyb@fuzziesquirrel.com> <radsquirrel!>
-M:  Joel Stanley <joel@jms.id.au>
diff --git a/meta-asrock/MAINTAINERS b/meta-asrock/MAINTAINERS
deleted file mode 100644
index ae85d83..0000000
--- a/meta-asrock/MAINTAINERS
+++ /dev/null
@@ -1,45 +0,0 @@
-How to use this list:
-    Find the most specific section entry (described below) that matches where
-    your change lives and add the reviewers (R) and maintainers (M) as
-    reviewers. You can use the same method to track down who knows a particular
-    code base best.
-
-    Your change/query may span multiple entries; that is okay.
-
-    If you do not find an entry that describes your request at all, someone
-    forgot to update this list; please at least file an issue or send an email
-    to a maintainer, but preferably you should just update this document.
-
-Description of section entries:
-
-    Section entries are structured according to the following scheme:
-
-    X:  NAME <EMAIL_USERNAME@DOMAIN> <DISCORD_USERNAME!>
-    X:  ...
-    .
-    .
-    .
-
-    Where REPO_NAME is the name of the repository within the OpenBMC GitHub
-    organization; FILE_PATH is a file path within the repository, possibly with
-    wildcards; X is a tag of one of the following types:
-
-    M:  Denotes maintainer; has fields NAME <EMAIL_USERNAME@DOMAIN> <DISCORD_USERNAME!>;
-        if omitted from an entry, assume one of the maintainers from the
-        MAINTAINERS entry.
-    R:  Denotes reviewer; has fields NAME <EMAIL_USERNAME@DOMAIN> <DISCORD_USERNAME!>;
-        these people are to be added as reviewers for a change matching the repo
-        path.
-    F:  Denotes forked from an external repository; has fields URL.
-
-    Line comments are to be denoted "# SOME COMMENT" (typical shell style
-    comment); it is important to follow the correct syntax and semantics as we
-    may want to use automated tools with this file in the future.
-
-    A change cannot be added to an OpenBMC repository without a MAINTAINER's
-    approval; thus, a MAINTAINER should always be listed as a reviewer.
-
-START OF MAINTAINERS LIST
--------------------------
-
-M:  Zev Weiss <zev@bewilderbeest.net> <zevweiss!>
diff --git a/meta-bytedance/MAINTAINERS b/meta-bytedance/MAINTAINERS
deleted file mode 100644
index c5f155b..0000000
--- a/meta-bytedance/MAINTAINERS
+++ /dev/null
@@ -1,46 +0,0 @@
-How to use this list:
-    Find the most specific section entry (described below) that matches where
-    your change lives and add the reviewers (R) and maintainers (M) as
-    reviewers. You can use the same method to track down who knows a particular
-    code base best.
-
-    Your change/query may span multiple entries; that is okay.
-
-    If you do not find an entry that describes your request at all, someone
-    forgot to update this list; please at least file an issue or send an email
-    to a maintainer, but preferably you should just update this document.
-
-Description of section entries:
-
-    Section entries are structured according to the following scheme:
-
-    X:  NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>
-    X:  ...
-    .
-    .
-    .
-
-    Where REPO_NAME is the name of the repository within the OpenBMC GitHub
-    organization; FILE_PATH is a file path within the repository, possibly with
-    wildcards; X is a tag of one of the following types:
-
-    M:  Denotes maintainer; has fields NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>;
-        if omitted from an entry, assume one of the maintainers from the
-        MAINTAINERS entry.
-    R:  Denotes reviewer; has fields NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>;
-        these people are to be added as reviewers for a change matching the repo
-        path.
-    F:  Denotes forked from an external repository; has fields URL.
-
-    Line comments are to be denoted "# SOME COMMENT" (typical shell style
-    comment); it is important to follow the correct syntax and semantics as we
-    may want to use automated tools with this file in the future.
-
-    A change cannot be added to an OpenBMC repository without a MAINTAINER's
-    approval; thus, a MAINTAINER should always be listed as a reviewer.
-
-START OF MAINTAINERS LIST
--------------------------
-
-M:  Lei YU <yulei.sh@bytedance.com> <LeiYU!>
-R:  Lotus Xu <xuxiaohan@bytedance.com>
diff --git a/meta-facebook/MAINTAINERS b/meta-facebook/MAINTAINERS
deleted file mode 100644
index a27fe90..0000000
--- a/meta-facebook/MAINTAINERS
+++ /dev/null
@@ -1,46 +0,0 @@
-How to use this list:
-    Find the most specific section entry (described below) that matches where
-    your change lives and add the reviewers (R) and maintainers (M) as
-    reviewers. You can use the same method to track down who knows a particular
-    code base best.
-
-    Your change/query may span multiple entries; that is okay.
-
-    If you do not find an entry that describes your request at all, someone
-    forgot to update this list; please at least file an issue or send an email
-    to a maintainer, but preferably you should just update this document.
-
-Description of section entries:
-
-    Section entries are structured according to the following scheme:
-
-    X:  NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>
-    X:  ...
-    .
-    .
-    .
-
-    Where REPO_NAME is the name of the repository within the OpenBMC GitHub
-    organization; FILE_PATH is a file path within the repository, possibly with
-    wildcards; X is a tag of one of the following types:
-
-    M:  Denotes maintainer; has fields NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>;
-        if omitted from an entry, assume one of the maintainers from the
-        MAINTAINERS entry.
-    R:  Denotes reviewer; has fields NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>;
-        these people are to be added as reviewers for a change matching the repo
-        path.
-    F:  Denotes forked from an external repository; has fields URL.
-
-    Line comments are to be denoted "# SOME COMMENT" (typical shell style
-    comment); it is important to follow the correct syntax and semantics as we
-    may want to use automated tools with this file in the future.
-
-    A change cannot be added to an OpenBMC repository without a MAINTAINER's
-    approval; thus, a MAINTAINER should always be listed as a reviewer.
-
-START OF MAINTAINERS LIST
--------------------------
-
-M:  Amithash Prasad <amithash@fb.com>
-M:  Patrick Williams <patrick@stwcx.xyz> <stwcx!>
diff --git a/meta-fii/MAINTAINERS b/meta-fii/MAINTAINERS
deleted file mode 100644
index 9be6f8a..0000000
--- a/meta-fii/MAINTAINERS
+++ /dev/null
@@ -1,49 +0,0 @@
-How to use this list:
-    Find the most specific section entry (described below) that matches where
-    your change lives and add the reviewers (R) and maintainers (M) as
-    reviewers. You can use the same method to track down who knows a particular
-    code base best.
-
-    Your change/query may span multiple entries; that is okay.
-
-    If you do not find an entry that describes your request at all, someone
-    forgot to update this list; please at least file an issue or send an email
-    to a maintainer, but preferably you should just update this document.
-
-Description of section entries:
-
-    Section entries are structured according to the following scheme:
-
-    X:  NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>
-    X:  ...
-    .
-    .
-    .
-
-    Where REPO_NAME is the name of the repository within the OpenBMC GitHub
-    organization; FILE_PATH is a file path within the repository, possibly with
-    wildcards; X is a tag of one of the following types:
-
-    M:  Denotes maintainer; has fields NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>;
-        if omitted from an entry, assume one of the maintainers from the
-        MAINTAINERS entry.
-    R:  Denotes reviewer; has fields NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>;
-        these people are to be added as reviewers for a change matching the repo
-        path.
-    F:  Denotes forked from an external repository; has fields URL.
-
-    Line comments are to be denoted "# SOME COMMENT" (typical shell style
-    comment); it is important to follow the correct syntax and semantics as we
-    may want to use automated tools with this file in the future.
-
-    A change cannot be added to an OpenBMC repository without a MAINTAINER's
-    approval; thus, a MAINTAINER should always be listed as a reviewer.
-
-START OF MAINTAINERS LIST
--------------------------
-
-M:  Benjamin Fair <benjaminfair@google.com> <benjaminfair!>
-M:  Vivekanand Veeracholan <vveerach@google.com> <vveerach!>
-M:  Lancelot Kao <lancelot.kao@fii-usa.com> <Lancelot-Kao!>
-M:  Mohaimen Alsamarai <Mohaimen.Alsamarai@fii-na.com> <Mohaimen13!>
-M:  XP Chen <Xiao-Peng.Chen@fii-na.com> <expeeee!>
diff --git a/meta-google/MAINTAINERS b/meta-google/MAINTAINERS
deleted file mode 100644
index 27ea1b5..0000000
--- a/meta-google/MAINTAINERS
+++ /dev/null
@@ -1,51 +0,0 @@
-How to use this list:
-    Find the most specific section entry (described below) that matches where
-    your change lives and add the reviewers (R) and maintainers (M) as
-    reviewers. You can use the same method to track down who knows a particular
-    code base best.
-
-    Your change/query may span multiple entries; that is okay.
-
-    If you do not find an entry that describes your request at all, someone
-    forgot to update this list; please at least file an issue or send an email
-    to a maintainer, but preferably you should just update this document.
-
-Description of section entries:
-
-    Section entries are structured according to the following scheme:
-
-    X:  NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>
-    X:  ...
-    .
-    .
-    .
-
-    Where REPO_NAME is the name of the repository within the OpenBMC GitHub
-    organization; FILE_PATH is a file path within the repository, possibly with
-    wildcards; X is a tag of one of the following types:
-
-    M:  Denotes maintainer; has fields NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>;
-        if omitted from an entry, assume one of the maintainers from the
-        MAINTAINERS entry.
-    R:  Denotes reviewer; has fields NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>;
-        these people are to be added as reviewers for a change matching the repo
-        path.
-    F:  Denotes forked from an external repository; has fields URL.
-
-    Line comments are to be denoted "# SOME COMMENT" (typical shell style
-    comment); it is important to follow the correct syntax and semantics as we
-    may want to use automated tools with this file in the future.
-
-    A change cannot be added to an OpenBMC repository without a MAINTAINER's
-    approval; thus, a MAINTAINER should always be listed as a reviewer.
-
-START OF MAINTAINERS LIST
--------------------------
-
-M:  Nancy Yuen <yuenn@google.com> <yuennancy!>
-M:  William Kennington <wak@google.com> <wak-work!>
-M:  Benjamin Fair <benjaminfair@google.com> <benjaminfair!>
-M:  Ed Tanous <edtanous@google.com> <edtanous!>
-M:  Brandon Kim <brandonkim@google.com> <brandonk!>
-M:  Willy Tu <wltu@google.com> <wltu!>
-M:  Nan Zhou <nanzhoumails@gmail.com> <fighternan!>
diff --git a/meta-hpe/MAINTAINERS b/meta-hpe/MAINTAINERS
deleted file mode 100644
index 3fbcd38..0000000
--- a/meta-hpe/MAINTAINERS
+++ /dev/null
@@ -1,48 +0,0 @@
-How to use this list:
-    Find the most specific section entry (described below) that matches where
-    your change lives and add the reviewers (R) and maintainers (M) as
-    reviewers. You can use the same method to track down who knows a particular
-    code base best.
-
-    Your change/query may span multiple entries; that is okay.
-
-    If you do not find an entry that describes your request at all, someone
-    forgot to update this list; please at least file an issue or send an email
-    to a maintainer, but preferably you should just update this document.
-
-Description of section entries:
-
-    Section entries are structured according to the following scheme:
-
-    X:  NAME <EMAIL_USERNAME@DOMAIN> <DISCORD_USERNAME!>
-    X:  ...
-    .
-    .
-    .
-
-    Where REPO_NAME is the name of the repository within the OpenBMC GitHub
-    organization; FILE_PATH is a file path within the repository, possibly with
-    wildcards; X is a tag of one of the following types:
-
-    M:  Denotes maintainer; has fields NAME <EMAIL_USERNAME@DOMAIN> <DISCORD_USERNAME!>;
-        if omitted from an entry, assume one of the maintainers from the
-        MAINTAINERS entry.
-    R:  Denotes reviewer; has fields NAME <EMAIL_USERNAME@DOMAIN> <DISCORD_USERNAME!>;
-        these people are to be added as reviewers for a change matching the repo
-        path.
-    F:  Denotes forked from an external repository; has fields URL.
-
-    Line comments are to be denoted "# SOME COMMENT" (typical shell style
-    comment); it is important to follow the correct syntax and semantics as we
-    may want to use automated tools with this file in the future.
-
-    A change cannot be added to an OpenBMC repository without a MAINTAINER's
-    approval; thus, a MAINTAINER should always be listed as a reviewer.
-
-START OF MAINTAINERS LIST
--------------------------
-
-M:  Mike Garrett <mike.garrett@hpe.com>
-M:  Jean-Marie Verdun <jean-marie.verdun@hpe.com>
-M:  Nick Hawkins <nhawkins48@gmail.com>
-M:  Nick Pedrana <allan.pedrana@gmail.com>
diff --git a/meta-ibm/MAINTAINERS b/meta-ibm/MAINTAINERS
deleted file mode 100644
index 412d79d..0000000
--- a/meta-ibm/MAINTAINERS
+++ /dev/null
@@ -1,45 +0,0 @@
-How to use this list:
-    Find the most specific section entry (described below) that matches where
-    your change lives and add the reviewers (R) and maintainers (M) as
-    reviewers. You can use the same method to track down who knows a particular
-    code base best.
-
-    Your change/query may span multiple entries; that is okay.
-
-    If you do not find an entry that describes your request at all, someone
-    forgot to update this list; please at least file an issue or send an email
-    to a maintainer, but preferably you should just update this document.
-
-Description of section entries:
-
-    Section entries are structured according to the following scheme:
-
-    X:  NAME <EMAIL_USERNAME@DOMAIN> <DISCORD_USERNAME!>
-    X:  ...
-    .
-    .
-    .
-
-    Where REPO_NAME is the name of the repository within the OpenBMC GitHub
-    organization; FILE_PATH is a file path within the repository, possibly with
-    wildcards; X is a tag of one of the following types:
-
-    M:  Denotes maintainer; has fields NAME <EMAIL_USERNAME@DOMAIN> <DISCORD_USERNAME!>;
-        if omitted from an entry, assume one of the maintainers from the
-        MAINTAINERS entry.
-    R:  Denotes reviewer; has fields NAME <EMAIL_USERNAME@DOMAIN> <DISCORD_USERNAME!>;
-        these people are to be added as reviewers for a change matching the repo
-        path.
-    F:  Denotes forked from an external repository; has fields URL.
-
-    Line comments are to be denoted "# SOME COMMENT" (typical shell style
-    comment); it is important to follow the correct syntax and semantics as we
-    may want to use automated tools with this file in the future.
-
-    A change cannot be added to an OpenBMC repository without a MAINTAINER's
-    approval; thus, a MAINTAINER should always be listed as a reviewer.
-
-START OF MAINTAINERS LIST
--------------------------
-
-M:  Andrew Geissler <geissonator@yahoo.com> <geissonator!>
diff --git a/meta-inspur/MAINTAINERS b/meta-inspur/MAINTAINERS
deleted file mode 100644
index 0710437..0000000
--- a/meta-inspur/MAINTAINERS
+++ /dev/null
@@ -1,46 +0,0 @@
-How to use this list:
-    Find the most specific section entry (described below) that matches where
-    your change lives and add the reviewers (R) and maintainers (M) as
-    reviewers. You can use the same method to track down who knows a particular
-    code base best.
-
-    Your change/query may span multiple entries; that is okay.
-
-    If you do not find an entry that describes your request at all, someone
-    forgot to update this list; please at least file an issue or send an email
-    to a maintainer, but preferably you should just update this document.
-
-Description of section entries:
-
-    Section entries are structured according to the following scheme:
-
-    X:  NAME <EMAIL_USERNAME@DOMAIN> <DISCORD_USERNAME!>
-    X:  ...
-    .
-    .
-    .
-
-    Where REPO_NAME is the name of the repository within the OpenBMC GitHub
-    organization; FILE_PATH is a file path within the repository, possibly with
-    wildcards; X is a tag of one of the following types:
-
-    M:  Denotes maintainer; has fields NAME <EMAIL_USERNAME@DOMAIN> <DISCORD_USERNAME!>;
-        if omitted from an entry, assume one of the maintainers from the
-        MAINTAINERS entry.
-    R:  Denotes reviewer; has fields NAME <EMAIL_USERNAME@DOMAIN> <DISCORD_USERNAME!>;
-        these people are to be added as reviewers for a change matching the repo
-        path.
-    F:  Denotes forked from an external repository; has fields URL.
-
-    Line comments are to be denoted "# SOME COMMENT" (typical shell style
-    comment); it is important to follow the correct syntax and semantics as we
-    may want to use automated tools with this file in the future.
-
-    A change cannot be added to an OpenBMC repository without a MAINTAINER's
-    approval; thus, a MAINTAINER should always be listed as a reviewer.
-
-START OF MAINTAINERS LIST
--------------------------
-
-M:  George Liu <liuxiwei@inspur.com> <liuxiwei!>
-R:  Lei Yu <mine260309@gmail.com> <LeiYU!>
diff --git a/meta-intel-openbmc/MAINTAINERS b/meta-intel-openbmc/MAINTAINERS
deleted file mode 100644
index 9a27e5d..0000000
--- a/meta-intel-openbmc/MAINTAINERS
+++ /dev/null
@@ -1,66 +0,0 @@
-List of maintainers for meta-intel
-===============================
-
-How to use this list:
-    Find the most specific section entry (described below) that matches where
-    your change lives and add the reviewers (R) and maintainers (M) as
-    reviewers. You can use the same method to track down who knows a particular
-    code base best.
-
-    Your change/query may span multiple entries; that is okay.
-
-    If you do not find an entry that describes your request at all, someone
-    forgot to update this list; please at least file an issue or send an email
-    to a maintainer, but preferably you should just update this document.
-
-Description of section entries:
-
-    Section entries are structured according to the following scheme:
-
-    X:  NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>
-    X:  ...
-    .
-    .
-    .
-
-    Where REPO_NAME is the name of the repository within the OpenBMC GitHub
-    organization; FILE_PATH is a file path within the repository, possibly with
-    wildcards; X is a tag of one of the following types:
-
-    M:  Denotes maintainer; has fields NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>;
-        if omitted from an entry, assume one of the maintainers from the
-        MAINTAINERS entry.
-    R:  Denotes reviewer; has fields NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>;
-        these people are to be added as reviewers for a change matching the repo
-        path.
-    F:  Denotes forked from an external repository; has fields URL.
-
-    Line comments are to be denoted "# SOME COMMENT" (typical shell style
-    comment); it is important to follow the correct syntax and semantics as we
-    may want to use automated tools with this file in the future.
-
-    A change cannot be added to an OpenBMC repository without a MAINTAINER's
-    approval; thus, a MAINTAINER should always be listed as a reviewer.
-
-Change approval rules:
-
-    - Patches must be available for review for a minimum of 48 hours before it
-      can be submitted.
-    - Patches must be be approved (+1) by at least 2 maintainers.
-    - Patches must not have an unresolved -1 vote by any maintainer.
-    - Patches should have all maintainers added for visibility.
-    - Patches should include unit tests where possible.
-    - Feel free to ping on IRC about patches that look good but have not
-      received +2
-
-Design approval rules:
-
-    - Design discussions should be carried out via email with, at minimum,
-      all maintainers on the thread.  It's encouraged to include the
-      OpenBMC mailing list in the thread as well.
-
-START OF MAINTAINERS LIST
--------------------------
-
-M:  Vernon Mauery <vernon.mauery@linux.intel.com> <vmauery!>
-M:  Jason Bills <jason.m.bills@linux.intel.com> <jmbills!>
diff --git a/meta-inventec/MAINTAINERS b/meta-inventec/MAINTAINERS
deleted file mode 100644
index 83ff5a0..0000000
--- a/meta-inventec/MAINTAINERS
+++ /dev/null
@@ -1,46 +0,0 @@
-How to use this list:
-    Find the most specific section entry (described below) that matches where
-    your change lives and add the reviewers (R) and maintainers (M) as
-    reviewers. You can use the same method to track down who knows a particular
-    code base best.
-
-    Your change/query may span multiple entries; that is okay.
-
-    If you do not find an entry that describes your request at all, someone
-    forgot to update this list; please at least file an issue or send an email
-    to a maintainer, but preferably you should just update this document.
-
-Description of section entries:
-
-    Section entries are structured according to the following scheme:
-
-    X:  NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>
-    X:  ...
-    .
-    .
-    .
-
-    Where REPO_NAME is the name of the repository within the OpenBMC GitHub
-    organization; FILE_PATH is a file path within the repository, possibly with
-    wildcards; X is a tag of one of the following types:
-
-    M:  Denotes maintainer; has fields NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>;
-        if omitted from an entry, assume one of the maintainers from the
-        MAINTAINERS entry.
-    R:  Denotes reviewer; has fields NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>;
-        these people are to be added as reviewers for a change matching the repo
-        path.
-    F:  Denotes forked from an external repository; has fields URL.
-
-    Line comments are to be denoted "# SOME COMMENT" (typical shell style
-    comment); it is important to follow the correct syntax and semantics as we
-    may want to use automated tools with this file in the future.
-
-    A change cannot be added to an OpenBMC repository without a MAINTAINER's
-    approval; thus, a MAINTAINER should always be listed as a reviewer.
-
-START OF MAINTAINERS LIST
--------------------------
-
-M:  Habeeb Mohammed <mohammed.habeeb@inventec.com>
-M:  Ye Vic <ye.vic@inventec.com>
diff --git a/meta-nuvoton/MAINTAINERS b/meta-nuvoton/MAINTAINERS
deleted file mode 100644
index 4207abd..0000000
--- a/meta-nuvoton/MAINTAINERS
+++ /dev/null
@@ -1,52 +0,0 @@
-How to use this list:
-    Find the most specific section entry (described below) that matches where
-    your change lives and add the reviewers (R) and maintainers (M) as
-    reviewers. You can use the same method to track down who knows a particular
-    code base best.
-
-    Your change/query may span multiple entries; that is okay.
-
-    If you do not find an entry that describes your request at all, someone
-    forgot to update this list; please at least file an issue or send an email
-    to a maintainer, but preferably you should just update this document.
-
-Description of section entries:
-
-    Section entries are structured according to the following scheme:
-
-    X:  NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>
-    X:  ...
-    .
-    .
-    .
-
-    Where REPO_NAME is the name of the repository within the OpenBMC GitHub
-    organization; FILE_PATH is a file path within the repository, possibly with
-    wildcards; X is a tag of one of the following types:
-
-    M:  Denotes maintainer; has fields NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>;
-        if omitted from an entry, assume one of the maintainers from the
-        MAINTAINERS entry.
-    R:  Denotes reviewer; has fields NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>;
-        these people are to be added as reviewers for a change matching the repo
-        path.
-    F:  Denotes forked from an external repository; has fields URL.
-
-    Line comments are to be denoted "# SOME COMMENT" (typical shell style
-    comment); it is important to follow the correct syntax and semantics as we
-    may want to use automated tools with this file in the future.
-
-    A change cannot be added to an OpenBMC repository without a MAINTAINER's
-    approval; thus, a MAINTAINER should always be listed as a reviewer.
-
-START OF MAINTAINERS LIST
--------------------------
-
-M:  Benjamin Fair <benjaminfair@google.com> <benjaminfair!>
-R:  Fran Hsu <fran.hsu@quantatw.com> <franhsu!>
-R:  Tomer Maimon <tmaimon77@gmail.com>
-R:  Tyrone Ting <kfting@nuvoton.com>
-R:  Joseph Liu <kwliu@nuvoton.com>
-R:  Samuel Jiang <chyishian.jiang@gmail.com>
-R:  Stanley Chu <yschu@nuvoton.com>
-R:  George Hung <george.hung@quantatw.com>
diff --git a/meta-openpower/MAINTAINERS b/meta-openpower/MAINTAINERS
deleted file mode 100644
index 565d46c..0000000
--- a/meta-openpower/MAINTAINERS
+++ /dev/null
@@ -1,46 +0,0 @@
-How to use this list:
-    Find the most specific section entry (described below) that matches where
-    your change lives and add the reviewers (R) and maintainers (M) as
-    reviewers. You can use the same method to track down who knows a particular
-    code base best.
-
-    Your change/query may span multiple entries; that is okay.
-
-    If you do not find an entry that describes your request at all, someone
-    forgot to update this list; please at least file an issue or send an email
-    to a maintainer, but preferably you should just update this document.
-
-Description of section entries:
-
-    Section entries are structured according to the following scheme:
-
-    X:  NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>
-    X:  ...
-    .
-    .
-    .
-
-    Where REPO_NAME is the name of the repository within the OpenBMC GitHub
-    organization; FILE_PATH is a file path within the repository, possibly with
-    wildcards; X is a tag of one of the following types:
-
-    M:  Denotes maintainer; has fields NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>;
-        if omitted from an entry, assume one of the maintainers from the
-        MAINTAINERS entry.
-    R:  Denotes reviewer; has fields NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>;
-        these people are to be added as reviewers for a change matching the repo
-        path.
-    F:  Denotes forked from an external repository; has fields URL.
-
-    Line comments are to be denoted "# SOME COMMENT" (typical shell style
-    comment); it is important to follow the correct syntax and semantics as we
-    may want to use automated tools with this file in the future.
-
-    A change cannot be added to an OpenBMC repository without a MAINTAINER's
-    approval; thus, a MAINTAINER should always be listed as a reviewer.
-
-START OF MAINTAINERS LIST
--------------------------
-
-M:  Joel Stanley <joel@jms.id.au> <shenki!>
-M:  Andrew Geissler <geissonator@yahoo.com> <geissonator!>
diff --git a/meta-phosphor/MAINTAINERS b/meta-phosphor/MAINTAINERS
deleted file mode 100644
index 81dd7c5..0000000
--- a/meta-phosphor/MAINTAINERS
+++ /dev/null
@@ -1,46 +0,0 @@
-How to use this list:
-    Find the most specific section entry (described below) that matches where
-    your change lives and add the reviewers (R) and maintainers (M) as
-    reviewers. You can use the same method to track down who knows a particular
-    code base best.
-
-    Your change/query may span multiple entries; that is okay.
-
-    If you do not find an entry that describes your request at all, someone
-    forgot to update this list; please at least file an issue or send an email
-    to a maintainer, but preferably you should just update this document.
-
-Description of section entries:
-
-    Section entries are structured according to the following scheme:
-
-    X:  NAME <EMAIL_USERNAME@DOMAIN> <DISCORD_USERNAME!>
-    X:  ...
-    .
-    .
-    .
-
-    Where REPO_NAME is the name of the repository within the OpenBMC GitHub
-    organization; FILE_PATH is a file path within the repository, possibly with
-    wildcards; X is a tag of one of the following types:
-
-    M:  Denotes maintainer; has fields NAME <EMAIL_USERNAME@DOMAIN> <DISCORD_USERNAME!>;
-        if omitted from an entry, assume one of the maintainers from the
-        MAINTAINERS entry.
-    R:  Denotes reviewer; has fields NAME <EMAIL_USERNAME@DOMAIN> <DISCORD_USERNAME!>;
-        these people are to be added as reviewers for a change matching the repo
-        path.
-    F:  Denotes forked from an external repository; has fields URL.
-
-    Line comments are to be denoted "# SOME COMMENT" (typical shell style
-    comment); it is important to follow the correct syntax and semantics as we
-    may want to use automated tools with this file in the future.
-
-    A change cannot be added to an OpenBMC repository without a MAINTAINER's
-    approval; thus, a MAINTAINER should always be listed as a reviewer.
-
-START OF MAINTAINERS LIST
--------------------------
-
-M:  Brad Bishop <bradleyb@fuzziesquirrel.com> <radsquirrel!>
-M:  Andrew Geissler <geissonator@yahoo.com> <geissonator!>
diff --git a/meta-quanta/MAINTAINERS b/meta-quanta/MAINTAINERS
deleted file mode 100644
index 5bb6a2f..0000000
--- a/meta-quanta/MAINTAINERS
+++ /dev/null
@@ -1,49 +0,0 @@
-How to use this list:
-    Find the most specific section entry (described below) that matches where
-    your change lives and add the reviewers (R) and maintainers (M) as
-    reviewers. You can use the same method to track down who knows a particular
-    code base best.
-
-    Your change/query may span multiple entries; that is okay.
-
-    If you do not find an entry that describes your request at all, someone
-    forgot to update this list; please at least file an issue or send an email
-    to a maintainer, but preferably you should just update this document.
-
-Description of section entries:
-
-    Section entries are structured according to the following scheme:
-
-    X:  NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>
-    X:  ...
-    .
-    .
-    .
-
-    Where REPO_NAME is the name of the repository within the OpenBMC GitHub
-    organization; FILE_PATH is a file path within the repository, possibly with
-    wildcards; X is a tag of one of the following types:
-
-    M:  Denotes maintainer; has fields NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>;
-        if omitted from an entry, assume one of the maintainers from the
-        MAINTAINERS entry.
-    R:  Denotes reviewer; has fields NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>;
-        these people are to be added as reviewers for a change matching the repo
-        path.
-    F:  Denotes forked from an external repository; has fields URL.
-
-    Line comments are to be denoted "# SOME COMMENT" (typical shell style
-    comment); it is important to follow the correct syntax and semantics as we
-    may want to use automated tools with this file in the future.
-
-    A change cannot be added to an OpenBMC repository without a MAINTAINER's
-    approval; thus, a MAINTAINER should always be listed as a reviewer.
-
-START OF MAINTAINERS LIST
--------------------------
-
-M:  Benjamin Fair <benjaminfair@google.com> <benjaminfair!>
-M:  Brandon Kim <brandonkim@google.com> <brandonk!>
-M:  Fran Hsu <fran.hsu@quantatw.com> <franhsu!>
-M:  George Hung <george.hung@quantatw.com> <ghung!>
-R:  Buddy Huang <buddy.huang@quantatw.com> <buddyhunag!>
diff --git a/meta-supermicro/MAINTAINERS b/meta-supermicro/MAINTAINERS
deleted file mode 100644
index 27d8988..0000000
--- a/meta-supermicro/MAINTAINERS
+++ /dev/null
@@ -1,47 +0,0 @@
-How to use this list:
-    Find the most specific section entry (described below) that matches where
-    your change lives and add the reviewers (R) and maintainers (M) as
-    reviewers. You can use the same method to track down who knows a particular
-    code base best.
-
-    Your change/query may span multiple entries; that is okay.
-
-    If you do not find an entry that describes your request at all, someone
-    forgot to update this list; please at least file an issue or send an email
-    to a maintainer, but preferably you should just update this document.
-
-Description of section entries:
-
-    Section entries are structured according to the following scheme:
-
-    X:  NAME <EMAIL_USERNAME@DOMAIN> <DISCORD_USERNAME!>
-    X:  ...
-    .
-    .
-    .
-
-    Where REPO_NAME is the name of the repository within the OpenBMC GitHub
-    organization; FILE_PATH is a file path within the repository, possibly with
-    wildcards; X is a tag of one of the following types:
-
-    M:  Denotes maintainer; has fields NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>;
-        if omitted from an entry, assume one of the maintainers from the
-        MAINTAINERS entry.
-    R:  Denotes reviewer; has fields NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>;
-        these people are to be added as reviewers for a change matching the repo
-        path.
-    F:  Denotes forked from an external repository; has fields URL.
-
-    Line comments are to be denoted "# SOME COMMENT" (typical shell style
-    comment); it is important to follow the correct syntax and semantics as we
-    may want to use automated tools with this file in the future.
-
-    A change cannot be added to an OpenBMC repository without a MAINTAINER's
-    approval; thus, a MAINTAINER should always be listed as a reviewer.
-
-START OF MAINTAINERS LIST
--------------------------
-
-M:  Ryan Sie <RyanS@supermicro.com.tw> <RyanSie!>
-M:  Ryan Zhou <RyanZ@supermicro.com>
-M:  Kevin Cheng <KevinCheng@supermicro.com.tw>
diff --git a/meta-yadro/MAINTAINERS b/meta-yadro/MAINTAINERS
deleted file mode 100644
index 6b1b602..0000000
--- a/meta-yadro/MAINTAINERS
+++ /dev/null
@@ -1,48 +0,0 @@
-How to use this list:
-    Find the most specific section entry (described below) that matches where
-    your change lives and add the reviewers (R) and maintainers (M) as
-    reviewers. You can use the same method to track down who knows a particular
-    code base best.
-
-    Your change/query may span multiple entries; that is okay.
-
-    If you do not find an entry that describes your request at all, someone
-    forgot to update this list; please at least file an issue or send an email
-    to a maintainer, but preferably you should just update this document.
-
-Description of section entries:
-
-    Section entries are structured according to the following scheme:
-
-    X:  NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>
-    X:  ...
-    .
-    .
-    .
-
-    Where REPO_NAME is the name of the repository within the OpenBMC GitHub
-    organization; FILE_PATH is a file path within the repository, possibly with
-    wildcards; X is a tag of one of the following types:
-
-    M:  Denotes maintainer; has fields NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>;
-        if omitted from an entry, assume one of the maintainers from the
-        MAINTAINERS entry.
-    R:  Denotes reviewer; has fields NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>;
-        these people are to be added as reviewers for a change matching the repo
-        path.
-    F:  Denotes forked from an external repository; has fields URL.
-
-    Line comments are to be denoted "# SOME COMMENT" (typical shell style
-    comment); it is important to follow the correct syntax and semantics as we
-    may want to use automated tools with this file in the future.
-
-    A change cannot be added to an OpenBMC repository without a MAINTAINER's
-    approval; thus, a MAINTAINER should always be listed as a reviewer.
-
-START OF MAINTAINERS LIST
--------------------------
-
-M:  Alexander Filippov <a.filippov@yadro.com> <nest1ing!>
-M:  Alexander Amelkin <a.amelkin@yadro.com> <AAmelkin_YADRO!>
-R:  Artem Senichev <artemsen@gmail.com> <artemsen!>
-R:  Andrei Kartashev <a.kartashev@yadro.com> <alatar!>