[xen stable-4.18] update Xen version to 4.18.1-pre

[patchbot@xxxxxxx]

commit 02f8d0adfba154664376a5c5dc8af3c927c79226
Author:     Jan Beulich <jbeulich@xxxxxxxx>
AuthorDate: Thu Nov 23 12:09:43 2023 +0100
Commit:     Jan Beulich <jbeulich@xxxxxxxx>
CommitDate: Thu Nov 23 12:09:43 2023 +0100

    update Xen version to 4.18.1-pre
---
 Config.mk    |   2 --
 MAINTAINERS  | 106 +++++------------------------------------------------------
 xen/Makefile |   2 +-
 3 files changed, 10 insertions(+), 100 deletions(-)

diff --git a/Config.mk b/Config.mk
index 5cf610c2fd..29b0d1e12a 100644
--- a/Config.mk
+++ b/Config.mk
@@ -236,8 +236,6 @@ ETHERBOOT_NICS ?= rtl8139 8086100e
 
 QEMU_TRADITIONAL_URL ?= 
https://xenbits.xen.org/git-http/qemu-xen-traditional.git
 QEMU_TRADITIONAL_REVISION ?= xen-4.18.0
-# Wed Jul 15 10:01:40 2020 +0100
-# qemu-trad: remove Xen path dependencies
 
 # Specify which qemu-dm to use. This may be `ioemu' to use the old
 # Mercurial in-tree version, or a local directory, or a git URL.
diff --git a/MAINTAINERS b/MAINTAINERS
index f61b5a32a1..c58e4615ab 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -54,6 +54,15 @@ list. Remember to copy the appropriate stable branch 
maintainer who
 will be listed in this section of the MAINTAINERS file in the
 appropriate branch.
 
+The maintainer for this branch is:
+
+       Jan Beulich <jbeulich@xxxxxxxx>
+
+Tools backport requests should also be copied to:
+
+       Anthony Perard <anthony.perard@xxxxxxxxxx>
+
+
        Unstable Subsystem Maintainers
        ==============================
 
@@ -104,103 +113,6 @@ Descriptions of section entries:
           xen-maintainers-<version format number of this file>
 
 
-       Check-in policy
-       ===============
-
-In order for a patch to be checked in, in general, several conditions
-must be met:
-
-1. In order to get a change to a given file committed, it must have
-   the approval of at least one maintainer of that file.
-
-   A patch of course needs Acks from the maintainers of each file that
-   it changes; so a patch which changes xen/arch/x86/traps.c,
-   xen/arch/x86/mm/p2m.c, and xen/arch/x86/mm/shadow/multi.c would
-   require an Ack from each of the three sets of maintainers.
-
-   See below for rules on nested maintainership.
-
-2. Each change must have appropriate approval from someone other than
-   the person who wrote it.  This can be either:
-
-  a. An Acked-by from a maintainer of the code being touched (a
-     co-maintainer if available, or a more general level maintainer if
-     not available; see the secton on nested maintainership)
-
-  b. A Reviewed-by by anyone of suitable stature in the community
-
-3. Sufficient time must have been given for anyone to respond.  This
-   depends in large part upon the urgency and nature of the patch.
-   For a straightforward uncontroversial patch, a day or two may be
-   sufficient; for a controversial patch, a week or two may be better.
-
-4. There must be no "open" objections.
-
-In a case where one person submits a patch and a maintainer gives an
-Ack, the Ack stands in for both the approval requirement (#1) and the
-Acked-by-non-submitter requirement (#2).
-
-In a case where a maintainer themselves submits a patch, the
-Signed-off-by meets the approval requirement (#1); so a Review
-from anyone in the community suffices for requirement #2.
-
-Before a maintainer checks in their own patch with another community
-member's R-b but no co-maintainer Ack, it is especially important to
-give their co-maintainer opportunity to give feedback, perhaps
-declaring their intention to check it in without their co-maintainers
-ack a day before doing so.
-
-In the case where two people collaborate on a patch, at least one of
-whom is a maintainer -- typically where one maintainer will do an
-early version of the patch, and another maintainer will pick it up and
-revise it -- there should be two Signed-off-by's and one Acked-by or
-Reviewed-by; with the maintainer who did the most recent change
-sending the patch, and an Acked-by or Reviewed-by coming from the
-maintainer who did not most recently edit the patch.  This satisfies
-the requirement #2 because a) the Signed-off-by of the sender approves
-the final version of the patch; including all parts of the patch that
-the sender did not write b) the Reviewed-by approves the final version
-of the patch, including all patches that the reviewer did not write.
-Thus all code in the patch has been approved by someone who did not
-write it.
-
-Maintainers may choose to override non-maintainer objections in the
-case that consensus can't be reached.
-
-As always, no policy can cover all possible situations.  In
-exceptional circumstances, committers may commit a patch in absence of
-one or more of the above requirements, if they are reasonably
-confident that the other maintainers will approve of their decision in
-retrospect.
-
-       The meaning of nesting
-       ======================
-
-Many maintainership areas are "nested": for example, there are entries
-for xen/arch/x86 as well as xen/arch/x86/mm, and even
-xen/arch/x86/mm/shadow; and there is a section at the end called "THE
-REST" which lists all committers.  The meaning of nesting is that:
-
-1. Under normal circumstances, the Ack of the most specific maintainer
-is both necessary and sufficient to get a change to a given file
-committed.  So a change to xen/arch/x86/mm/shadow/multi.c requires the
-the Ack of the xen/arch/x86/mm/shadow maintainer for that part of the
-patch, but would not require the Ack of the xen/arch/x86 maintainer or
-the xen/arch/x86/mm maintainer.
-
-2. In unusual circumstances, a more general maintainer's Ack can stand
-in for or even overrule a specific maintainer's Ack.  Unusual
-circumstances might include:
- - The patch is fixing a high-priority issue causing immediate pain,
- and the more specific maintainer is not available.
- - The more specific maintainer has not responded either to the
- original patch, nor to "pings", within a reasonable amount of time.
- - The more general maintainer wants to overrule the more specific
- maintainer on some issue. (This should be exceptional.)
- - In the case of a disagreement between maintainers, THE REST can
- settle the matter by majority vote.  (This should be very exceptional
- indeed.)
-
 
 Maintainers List (try to look for most precise areas first)
 
diff --git a/xen/Makefile b/xen/Makefile
index b8de14dce1..e39290f638 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -6,7 +6,7 @@ this-makefile := $(call lastword,$(MAKEFILE_LIST))
 # All other places this is stored (eg. compile.h) should be autogenerated.
 export XEN_VERSION       = 4
 export XEN_SUBVERSION    = 18
-export XEN_EXTRAVERSION ?= .0$(XEN_VENDORVERSION)
+export XEN_EXTRAVERSION ?= .1-pre$(XEN_VENDORVERSION)
 export XEN_FULLVERSION   = $(XEN_VERSION).$(XEN_SUBVERSION)$(XEN_EXTRAVERSION)
 -include xen-version
 
--
generated by git-patchbot for /home/xen/git/xen.git#stable-4.18