diff options
Diffstat (limited to '0001-update-Xen-version-to-4.17.1-pre.patch')
| -rw-r--r-- | 0001-update-Xen-version-to-4.17.1-pre.patch | 136 |
1 files changed, 136 insertions, 0 deletions
diff --git a/0001-update-Xen-version-to-4.17.1-pre.patch b/0001-update-Xen-version-to-4.17.1-pre.patch new file mode 100644 index 0000000..1d1bb53 --- /dev/null +++ b/0001-update-Xen-version-to-4.17.1-pre.patch @@ -0,0 +1,136 @@ +From 0b999fa2eadaeff840a8331b87f1f73abf3b14eb Mon Sep 17 00:00:00 2001 +From: Jan Beulich <jbeulich@suse.com> +Date: Tue, 20 Dec 2022 13:40:38 +0100 +Subject: [PATCH 01/89] update Xen version to 4.17.1-pre + +--- + MAINTAINERS | 92 +++++----------------------------------------------- + xen/Makefile | 2 +- + 2 files changed, 10 insertions(+), 84 deletions(-) + +diff --git a/MAINTAINERS b/MAINTAINERS +index 175f10f33f..ebb908cc37 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@suse.com> ++ ++Tools backport requests should also be copied to: ++ ++ Anthony Perard <anthony.perard@citrix.com> ++ ++ + Unstable Subsystem Maintainers + ============================== + +@@ -104,89 +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. It must have appropriate approval from someone other than the +- submitter. 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. +- +-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 d7102a3b47..dcedfbc38e 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 = 17 +-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 + +-- +2.40.0 + |