Release criteria: virtualization tweak

[agraham]

On 09/08/2011 07:26 PM, Adam Williamson wrote:
> On Thu, 2011-09-08 at 19:19 +0100, agraham wrote:
>
>>> I'm still not super happy with the wording, but I guess it's clearer.
>>> Any better ideas?
>>
>> Suggestions:
>>
>> A Fedora release must be able host virtual guest instances of the same
>> Fedora release.
>
> Hum, I think that's pretty bulletproof, neat. pjones, does it read okay
> to you?
>
>> I think the last part of the original sentence is redundant.
>>
>> However, I'd prefer:
>>
>> A Fedora release must be able host virtual guest instances of the same
>> Fedora release as well as all previous Fedora releases.
>
> All previous - I don't think that's right. We only care about N and N-1,
> for virt purposes. Well, *maybe* N-2. We don't care about releases past
> N-2 for any purpose, they're unsupported. Note there's a subsequent
> criterion:

The statement is basically already true, assuming KVM:

http://www.linux-kvm.org/page/Guest_Support_Status
(FC2 is missing, but may have been missed).

>
> "The release must boot successfully as a virtual guest in a situation
> where the virtual host is running the previous stable Fedora release
> (using Fedora's current preferred virtualization technology) "
>
> which covers the 'host on N-1' case. 'Guest N-1 on Host N' isn't exactly
> covered right now, but then it's unlikely there'd be a bug in F16 which
> prevented an F16 system hosting an F15 guest, but allowed it to host an
> F16 guest...that'd more likely be the case if the bug was in F15...I
> guess?
>
>>
>> "Current preferred virtualization technology:"
>>
>> Is too ambiguous, lets call a spade a space and state KVM if that
>> statement is required.
>
> It's intentionally ambiguous: I try to write the criteria as generically
> as possible. This ensures we don't have to rewrite them just because we
> change tack. (Remember, our 'preferred virt technology' was Xen not so
> long ago; if we'd had hardcoded criteria that stated 'Xen' at that
> point, we'd have had to rewrite them to say 'KVM'). I think it's just
> more correct, too: our intent is not that 'KVM should work', really, our
> intent really is 'whatever Fedora currently reckons is The Good Stuff
> should work'. Same reason the criteria say 'the installer' and not
> 'anaconda', and 'refer generically to 'release-blocking desktops', not
> 'GNOME and KDE'.

I fully understand where you are coming from, when it comes to policy 
statements, they usually refer to now and possibly the past, but not 
future. because policies usually needs to change as you state.

Albert.