Message ID | 22358.53851.305858.396704@mariner.uk.xensource.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
>>> On 07.06.16 at 15:55, <Ian.Jackson@eu.citrix.com> wrote: > Ian Jackson writes ("Commit moratorium for branching 4.7"): >> At Wei's request, I am starting to branch the tree, so that >> xen-unstable can diverge from the *-4.7 preparation branches. >> >> Please don't commit anything until I'm done, which will be later >> today. > > I have now finished this branching process. Please let me know of any > anomalies. I have applied the patch below to xen.git#staging, to > (from a technical point of view) open Xen 4.8. > > I'm not sure we have made a community decision about the terms under > which patches may be committed to the newly-open 4.8 (and who is > responsible for porting bug fixes from 4.7 to 4.8 or vice versa). > Perhaps I missed the email. I don't think the stable tree maintainers > want to take over 4.7 yet. So until that is settled, probably nothing > substantial should be committed to 4.8. > > Commits for 4.7 should now go to xen.git#staging-4.7, on the same > terms as before. (Ie, with Wei's approval.) Perhaps we can use the same model as I think we used last time, with the person committing to unstable being responsible to also put things applicable to 4.7 there? And with that declare the tree open again for any changes not deemed likely to complicate eventual backports to 4.7? Jan
On 07/06/16 15:26, Jan Beulich wrote: >>>> On 07.06.16 at 15:55, <Ian.Jackson@eu.citrix.com> wrote: >> Ian Jackson writes ("Commit moratorium for branching 4.7"): >>> At Wei's request, I am starting to branch the tree, so that >>> xen-unstable can diverge from the *-4.7 preparation branches. >>> >>> Please don't commit anything until I'm done, which will be later >>> today. >> >> I have now finished this branching process. Please let me know of any >> anomalies. I have applied the patch below to xen.git#staging, to >> (from a technical point of view) open Xen 4.8. >> >> I'm not sure we have made a community decision about the terms under >> which patches may be committed to the newly-open 4.8 (and who is >> responsible for porting bug fixes from 4.7 to 4.8 or vice versa). >> Perhaps I missed the email. I don't think the stable tree maintainers >> want to take over 4.7 yet. So until that is settled, probably nothing >> substantial should be committed to 4.8. >> >> Commits for 4.7 should now go to xen.git#staging-4.7, on the same >> terms as before. (Ie, with Wei's approval.) > > Perhaps we can use the same model as I think we used last time, > with the person committing to unstable being responsible to also > put things applicable to 4.7 there? And with that declare the tree > open again for any changes not deemed likely to complicate > eventual backports to 4.7? +1
George Dunlap writes ("Re: Commit moratorium for branching 4.7"): > On 07/06/16 15:26, Jan Beulich wrote: > > Perhaps we can use the same model as I think we used last time, > > with the person committing to unstable being responsible to also > > put things applicable to 4.7 there? And with that declare the tree > > open again for any changes not deemed likely to complicate > > eventual backports to 4.7? > > +1 SGTM Ian.
On Tue, Jun 07, 2016 at 02:55:39PM +0100, Ian Jackson wrote: > Ian Jackson writes ("Commit moratorium for branching 4.7"): > > At Wei's request, I am starting to branch the tree, so that > > xen-unstable can diverge from the *-4.7 preparation branches. > > > > Please don't commit anything until I'm done, which will be later > > today. > > I have now finished this branching process. Please let me know of any > anomalies. I have applied the patch below to xen.git#staging, to > (from a technical point of view) open Xen 4.8. > > I'm not sure we have made a community decision about the terms under > which patches may be committed to the newly-open 4.8 (and who is > responsible for porting bug fixes from 4.7 to 4.8 or vice versa). > Perhaps I missed the email. I don't think the stable tree maintainers > want to take over 4.7 yet. So until that is settled, probably nothing > substantial should be committed to 4.8. > I forgot to send an email about this, sorry. From the point on up to the actual release, all committers are responsible for both 4.7 and -unstable branch. Bug fixes can be first committed -unstable (no RM ack needed) and then cherry-pick (with RM ack) to 4.7 branch. I don't expect there to be large number of patches though. Wei.
diff --git a/Config.mk b/Config.mk index bc5c456..e083727 100644 --- a/Config.mk +++ b/Config.mk @@ -17,7 +17,7 @@ or = $(if $(strip $(1)),$(1),$(if $(strip $(2)),$(2),$(if $(strip $(3)),$( -include $(XEN_ROOT)/.config # A debug build of Xen and tools? -debug ?= n +debug ?= y debug_symbols ?= $(debug) # Test coverage support @@ -272,7 +272,7 @@ SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git MINIOS_UPSTREAM_URL ?= git://xenbits.xen.org/mini-os.git endif OVMF_UPSTREAM_REVISION ?= 52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d -QEMU_UPSTREAM_REVISION ?= qemu-xen-4.7.0-rc5 +QEMU_UPSTREAM_REVISION ?= master MINIOS_UPSTREAM_REVISION ?= 1a3ee6eeca136525aa2e6917ae500e7cf731c09d # Fri May 13 15:21:10 2016 +0100 # lib/sys.c: enclose file_types in define guards diff --git a/README b/README index d3f432a..e1ac04a 100644 --- a/README +++ b/README @@ -1,10 +1,10 @@ ################################# -__ __ _ _ _____ -\ \/ /___ _ __ | || | |___ | _ __ ___ - \ // _ \ '_ \ | || |_ / /____| '__/ __| - / \ __/ | | | |__ _| / /_____| | | (__ -/_/\_\___|_| |_| |_|(_)_/ |_| \___| - +__ __ _ _ ___ _ _ _ +\ \/ /___ _ __ | || | ( _ ) _ _ _ __ ___| |_ __ _| |__ | | ___ + \ // _ \ '_ \ | || |_ / _ \ _____| | | | '_ \/ __| __/ _` | '_ \| |/ _ \ + / \ __/ | | | |__ _| (_) |_____| |_| | | | \__ \ || (_| | |_) | | __/ +/_/\_\___|_| |_| |_|(_)___/ \__,_|_| |_|___/\__\__,_|_.__/|_|\___| + ################################# http://www.xen.org/ diff --git a/xen/Makefile b/xen/Makefile index b59f95d..ee8ce8e 100644 --- a/xen/Makefile +++ b/xen/Makefile @@ -1,8 +1,8 @@ # This is the correct place to edit the build version. # All other places this is stored (eg. compile.h) should be autogenerated. export XEN_VERSION = 4 -export XEN_SUBVERSION = 7 -export XEN_EXTRAVERSION ?= .0-rc$(XEN_VENDORVERSION) +export XEN_SUBVERSION = 8 +export XEN_EXTRAVERSION ?= -unstable$(XEN_VENDORVERSION) export XEN_FULLVERSION = $(XEN_VERSION).$(XEN_SUBVERSION)$(XEN_EXTRAVERSION) -include xen-version