[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [xen stable-4.18] update Xen version to 4.18.1-pre
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |