The Xen Project team is pleased to announce the release of Xen 4.3. The result of nearly 10 of development, new features include: * Early support for ARM 32- and 64-bit architectures * qemu-upstream is now the default for VMs not using stub domains. * openvswitch hot-plug script support. * NUMA affinity for the scheduler * xl can now accept several USB devices, rather than only one. * XSM improvements. XSM can now override all IS_PRIV checks in the hypervisor. * As always, a number of stability, performance, and security enhancements "under the hood". Detailed release notes, including a more extensive feature list: http://wiki.xenproject.org/wiki/Xen_4.3_Release_Notes To download tarballs: http://www.xenproject.org/downloads/xen-archives/supported-xen-43-series/xen-430.html Or the git source repository (tag ''RELEASE-4.3.0''): http://xenbits.xen.org/gitweb/?p=xen.git And the announcement on the Xen blog: http://blog.xen.org/index.php/2013/07/09/xen-4-3-0-released/ Thanks to the many people who have contributed to this release! Regards, The Xen Project Team
On Tue, Jul 9, 2013 at 9:01 AM, George Dunlap <George.Dunlap@eu.citrix.com> wrote:> The Xen Project team is pleased to announce the release of Xen 4.3. > > The result of nearly 10 of development, new features include: > * Early support for ARM 32- and 64-bit architectures > * qemu-upstream is now the default for VMs not using stub domains. > * openvswitch hot-plug script support. > * NUMA affinity for the scheduler > * xl can now accept several USB devices, rather than only one. > * XSM improvements. XSM can now override all IS_PRIV checks in the hypervisor. > * As always, a number of stability, performance, and security > enhancements "under the hood". > > Detailed release notes, including a more extensive feature list: > http://wiki.xenproject.org/wiki/Xen_4.3_Release_Notes > > To download tarballs: > http://www.xenproject.org/downloads/xen-archives/supported-xen-43-series/xen-430.html > Or the git source repository (tag ''RELEASE-4.3.0''): > http://xenbits.xen.org/gitweb/?p=xen.git >Hi George, Thanks for all the effort in coordinating this release. Generally, I prefer to wait until things clear the necessary gates to get out of the staging-4.3 (or whatever staging tree) before rebasing our XenClient patches on top of it, as it usually means it passed some level of automated testing through osstest. In this case, the staging-4.3 tree is where the RELEASE-4.3.0 tag exists, but the stable-4.3 tag seems to be a handful of changesets behind, despite being released a couple days ago. Could you, or others comment on this discrepancy? Is the fact that the stable-4.3 tree is lagging behind the staging-4.3 branch an oversight, or has it not passed some push gate? Thanks again Ben> And the announcement on the Xen blog: > http://blog.xen.org/index.php/2013/07/09/xen-4-3-0-released/ > > Thanks to the many people who have contributed to this release! > > Regards, > The Xen Project Team > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
On 11/07/13 10:41, Ben Guthro wrote:> On Tue, Jul 9, 2013 at 9:01 AM, George Dunlap > <George.Dunlap@eu.citrix.com> wrote: >> The Xen Project team is pleased to announce the release of Xen 4.3. >> >> The result of nearly 10 of development, new features include: >> * Early support for ARM 32- and 64-bit architectures >> * qemu-upstream is now the default for VMs not using stub domains. >> * openvswitch hot-plug script support. >> * NUMA affinity for the scheduler >> * xl can now accept several USB devices, rather than only one. >> * XSM improvements. XSM can now override all IS_PRIV checks in the hypervisor. >> * As always, a number of stability, performance, and security >> enhancements "under the hood". >> >> Detailed release notes, including a more extensive feature list: >> http://wiki.xenproject.org/wiki/Xen_4.3_Release_Notes >> >> To download tarballs: >> http://www.xenproject.org/downloads/xen-archives/supported-xen-43-series/xen-430.html >> Or the git source repository (tag ''RELEASE-4.3.0''): >> http://xenbits.xen.org/gitweb/?p=xen.git >> > Hi George, > > Thanks for all the effort in coordinating this release. > > Generally, I prefer to wait until things clear the necessary gates to > get out of the staging-4.3 (or whatever staging tree) before rebasing > our XenClient patches on top of it, as it usually means it passed some > level of automated testing through osstest. > > In this case, the staging-4.3 tree is where the RELEASE-4.3.0 tag > exists, but the stable-4.3 tag seems to be a handful of changesets > behind, despite being released a couple days ago. > > Could you, or others comment on this discrepancy? > Is the fact that the stable-4.3 tree is lagging behind the staging-4.3 > branch an oversight, or has it not passed some push gate?The last few changes have not passed the push gate. Unfortunately, osstest died over the weekend, at the same time that Ian Jackson, who is in charge of it, fell dreadfully ill. By the time it was noticed, the announcement had already been given to the press. We had the choice of going through with the release with the last few changes not quite tested, or having an apology on the download page; and we had only a few hours or so to actually make a decision. Looking at the changesets, we decided that on the whole the best thing in the circumstances would be to do our own testing and then go through with the release. The tester ran on 4.3 for the first time this morning, and there was some issue with the QEMU tag. That will probably be sorted shortly. This has obviously highlighted a few deficiencies in the process that we''ll have to fix in future releases: * We should remove debug=y in the middle of RCs, to make sure we get good testing without that change made * If we''re going to do a big announcement, Linux Foundation-style, we need to have things branched, tagged and tested a week before the announcement. Any other feedback is also welcome. -George
----- Original Message -----> From: George Dunlap <george.dunlap@eu.citrix.com> > To: Ben Guthro <ben@guthro.net> > Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org> > Sent: Thursday, 11 July 2013, 13:29 > Subject: Re: [Xen-devel] Xen 4.3 released! > > On 11/07/13 10:41, Ben Guthro wrote: >> On Tue, Jul 9, 2013 at 9:01 AM, George Dunlap >> <George.Dunlap@eu.citrix.com> wrote: >>> The Xen Project team is pleased to announce the release of Xen 4.3. >>> >>> The result of nearly 10 of development, new features include: >>> * Early support for ARM 32- and 64-bit architectures >>> * qemu-upstream is now the default for VMs not using stub domains. >>> * openvswitch hot-plug script support. >>> * NUMA affinity for the scheduler >>> * xl can now accept several USB devices, rather than only one. >>> * XSM improvements. XSM can now override all IS_PRIV checks in the > hypervisor. >>> * As always, a number of stability, performance, and security >>> enhancements "under the hood". >>> >>> Detailed release notes, including a more extensive feature list: >>> http://wiki.xenproject.org/wiki/Xen_4.3_Release_Notes >>> >>> To download tarballs: >>> > http://www.xenproject.org/downloads/xen-archives/supported-xen-43-series/xen-430.html >>> Or the git source repository (tag ''RELEASE-4.3.0''): >>> http://xenbits.xen.org/gitweb/?p=xen.git >>> >> Hi George, >> >> Thanks for all the effort in coordinating this release. >> >> Generally, I prefer to wait until things clear the necessary gates to >> get out of the staging-4.3 (or whatever staging tree) before rebasing >> our XenClient patches on top of it, as it usually means it passed some >> level of automated testing through osstest. >> >> In this case, the staging-4.3 tree is where the RELEASE-4.3.0 tag >> exists, but the stable-4.3 tag seems to be a handful of changesets >> behind, despite being released a couple days ago. >> >> Could you, or others comment on this discrepancy? >> Is the fact that the stable-4.3 tree is lagging behind the staging-4.3 >> branch an oversight, or has it not passed some push gate? > > The last few changes have not passed the push gate. > > Unfortunately, osstest died over the weekend, at the same time that Ian > Jackson, who is in charge of it, fell dreadfully ill. By the time it > was noticed, the announcement had already been given to the press. We > had the choice of going through with the release with the last few > changes not quite tested, or having an apology on the download page; and > we had only a few hours or so to actually make a decision. > > Looking at the changesets, we decided that on the whole the best thing > in the circumstances would be to do our own testing and then go through > with the release. > > The tester ran on 4.3 for the first time this morning, and there was > some issue with the QEMU tag. That will probably be sorted shortly. > > This has obviously highlighted a few deficiencies in the process that > we''ll have to fix in future releases: > > * We should remove debug=y in the middle of RCs, to make sure we get > good testing without that change made > * If we''re going to do a big announcement, Linux Foundation-style, we > need to have things branched, tagged and tested a week before the > announcement. > > Any other feedback is also welcome.Fairplay for getting done what needed to be done. I did observe that in the absence of Ian J and step-by-step documentation, the process appeared to be somewhat made up as you were going along. I nearly posted at the time to remind all involved of the dangers of this. Of course we have all done it, when we had to. I didn''t post at the time, because I didn''t think it would be helpful. If I was me, though, I''d want it documented well enough that anyone with the access and the authority could perform the release.> > -George > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel >
On Thu, Jul 11, 2013 at 2:09 PM, Ian Murray <murrayie@yahoo.co.uk> wrote:> Fairplay for getting done what needed to be done. I did observe that in the absence of Ian J and step-by-step documentation, the process appeared to be somewhat made up as you were going along. I nearly posted at the time to remind all involved of the dangers of this. Of course we have all done it, when we had to. I didn''t post at the time, because I didn''t think it would be helpful. > > If I was me, though, I''d want it documented well enough that anyone with the access and the authority could perform the release.Ian''s list was mostly about what to do with branches, and all of it had already been done except for the actual tagging part. I think in the past Keir just did all of the make-the-release-ready stuff himself. -George
On 11/07/2013 15:59, "George Dunlap" <George.Dunlap@eu.citrix.com> wrote:> On Thu, Jul 11, 2013 at 2:09 PM, Ian Murray <murrayie@yahoo.co.uk> wrote: >> Fairplay for getting done what needed to be done. I did observe that in the >> absence of Ian J and step-by-step documentation, the process appeared to be >> somewhat made up as you were going along. I nearly posted at the time to >> remind all involved of the dangers of this. Of course we have all done it, >> when we had to. I didn''t post at the time, because I didn''t think it would be >> helpful. >> >> If I was me, though, I''d want it documented well enough that anyone with the >> access and the authority could perform the release. > > Ian''s list was mostly about what to do with branches, and all of it > had already been done except for the actual tagging part. I think in > the past Keir just did all of the make-the-release-ready stuff > himself.I did indeed. This is the first release where it''s all been handled by others, so there are some rough edges. It''s all good, it will get documented and improved for next time. -- Keir> -George > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
On 11/07/2013 16:13, Keir Fraser wrote:> On 11/07/2013 15:59, "George Dunlap" <George.Dunlap@eu.citrix.com> wrote: > >> On Thu, Jul 11, 2013 at 2:09 PM, Ian Murray <murrayie@yahoo.co.uk> wrote: >> >> If I was me, though, I''d want it documented well enough that anyone with the >> access and the authority could perform the release. >> Ian''s list was mostly about what to do with branches, and all of it >> had already been done except for the actual tagging part. I think in >> the past Keir just did all of the make-the-release-ready stuff >> himself. > I did indeed. This is the first release where it''s all been handled by > others, so there are some rough edges. It''s all good, it will get documented > and improved for next time. > > -- Keir >We should probably put up the checklist on the wiki. It''s good for transparency and will help in case somebody is ill during the release. We also learned a bit about the mechanics of press releases: basically they can''t be stopped once they are scheduled on the newswire. Thank you again to everyone for making the release happen on time (-: Lars