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, 0 insertions, 136 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 deleted file mode 100644 index 1d1bb53..0000000 --- a/0001-update-Xen-version-to-4.17.1-pre.patch +++ /dev/null @@ -1,136 +0,0 @@ -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 - |