[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen 4.1.x security support
> On 09/18/13 10:39, Jan Beulich wrote: >>>>> On 17.09.13 at 19:44, Joanna Rutkowska <joanna@xxxxxxxxxxxxxxxxxxxxxx> >>>>> wrote: >>> And a somehow more general thought: what most people expect from >>> baremetal hypervisors, I think, is stability. Unlike the Linux kernel, >>> the Xen hypervisor does not need to support each and every device >>> invented on the planet, each and every possible filesystem, or >>> networking stack, etc. That's, in fact, (one of) the biggest advantage >>> of a hypervisor over a monolithic kernel. So, why, oh why, such a race >>> to keep bumping the major version over and over again? >> >> In fact I'm the (so far apparently only) one trying to stop further >> accelerating the release schedule from its original 9 month cycle. >> I don't recall you having chimed in when the release schedule for >> 4.4 in particular and the shortening of the release cycle in general >> was discussed on the mailing list. There were arguments in favor >> of the shortening which I certainly appreciate. >> > > Well, I'm not regular on xen-devel, because I'm not a Xen developer, > really. I'm a _user_ of Xen. In an ideal world we (Qubes OS project) > should not even maintain a fork of Xen, nor be at xen-devel at all. > > I just came here now because I'm worried that the team I'm leading, the > users of Xen, will now need to spend considerable amount of time on > upgrading our product to Xen 4.2, because Xen 4.1 security support is > ending soon. Several communities are adopting the notion of LTS releases. Ubuntu Precise, for example, has been a major enabler in Openstack by offering a steady platform for over 18 months now. Upstream kernel 3.10 is slated to underpin major distros for a good while. I don't see why xen.org could not offer a similar cadence, and all the down streams would naturally align to that. Jan's point about keeping many stable trees being a significant time sink is extremely valid. I think the LTS solutions solves both of your problems. As a downstream, Qubes won't have to move rapidly crossing minor versions. There will be a reckoning day when transitioning to the next LTS, but you will have plenty of advance notice to prepare. The stable tree maintainer needs to care about a single tree which is a very well known quantity, and not have to deal with maybe two or even three trees at a time. One could argue that an LTS approach lessens the value of non LTS releases. In fact, discussions in Ubuntu have pointed at forgetting about non LTS releases and doing nightly builds in between, given a strong enough CI/CD environment. I for one think that's a bit too drastic and there is value to 4.3, 4.4, etc marking completion of important features. If we were to appoint an LTS, I would vote for 4.2, which saw a significant delta with respect to 4.1. If we were to appoint a 5.0, that would be a prime candidate for an LTS. Xend deprecation as well as fully-baked PVH would be two major milestones demarcating a clear before and after. My two cents Andres > I can imagine there are more users of Xen who would share > my worries, hopefully they will come to this threat sooner or later and > back me up :) > > joanna. > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |