Re: [Xen-devel] Xen 4.1.x security support

[Andres Lagar-Cavilla <andreslc@xxxxxxxxxxxxxx>]

> 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