Fw: MRE request: virtualbox

[Christopher James Halse Rogers]

Hi there!

Sorry for the delay in addressing this.

This does seem like Virtualbox fits well enough in the HWE category (and 
probably has sufficient upstream testing) for special SRU treatment.

I've taken the liberty of reworking the wiki page 
https://wiki.ubuntu.com/VirtualboxUpdates to make it easy to review and 
accept Virtualbox SRU bugs. I've done this to the best of my 
understanding, but you're the domain expert, so please check my work :)

Particularly: it's my understanding that this does *not* require any 
special coordination with the kernel - the Ubuntu kernel contains 
Virtualbox guest driver modules, but these are upstream kernel modules, 
and the Ubuntu kernel build does not build virtualbox-dkms modules at 
kernel-build time¹

I've also marked a couple of places (with *******s) where the test case 
instructions were not clear to me. The intent with test case 
documentation is that it should be detailed enough that anyone reading 
the bug could perform the steps and we could be confident that they have 
exercised the expected tests.

Specifically, the questions I had were:

* instructions for installing/removing the guest additions from the iso 
pack (or pointers to documentation for that)

* What the “various other tests” are - you mention changing 
configuration and vboxmanage?

* Do we need to verify that installing virtualbox guest packages 
*outside* a VM does not interfere with the system? There seems to have 
been at least one bug raised about that in the past.

Sorry again for the delay,

Chris Halse Rogers (SRU team member)


¹: Unlike, for example, zfs-dkms, where the kernel build process pulls a 
specific version of the zfs-dkms package from the archive, builds it, 
and includes the built modules in a package.

On 15/9/23 20:23, Gianfranco Costamagna wrote:
> Hello, I found that an MRE request was acked in 2015 for virtualbox, but since then, the workflow has changed a lot, so
> I'm asking again for an MRE exceptiom related to virtualbox.
> I already created the wiki page with the process, I will try to update it to match the current expectation criteria
> 
> https://wiki.ubuntu.com/VirtualboxUpdates
> 
> thanks for considering it
> 
> G.
> 
> 
> 
> 
> 
> 
> ----- Messaggio inoltrato -----
> 
> Da: Martin Pitt <martin.pitt at ubuntu.com>
> A: "costamagnagianfranco at yahoo.it" <costamagnagianfranco at yahoo.it>
> Cc: "technical-board at lists.ubuntu.com" <technical-board at lists.ubuntu.com>; "security at ubuntu.com" <security at ubuntu.com>
> Inviato: mercoledì 4 novembre 2015 alle ore 02:26:02 CET
> Oggetto: Re: MRE request: virtualbox
> 
> 
> Hello Gianfranco,
> 
> Gianfranco Costamagna [2015-10-29 18:50 +0100]:
>> I would like to apply for a micro release exception for Virtualbox
> 
> Since [1] we actually did away with (most) explicit MREs, and adjusted
> the SRU policy to generalize those.
> 
> [1] https://lists.ubuntu.com/archives/ubuntu-devel-announce/2015-September/001152.html
> 
>> Upstream:
>>
>>    - Micro releases happen from low-volume stable branches,
>>      approximately once every two months.
>>
>>    - Stable branches are supported with bug fixes for some years
>> (normally 5 years + 6 months or more).
>>
>>    - Upstream commits are reviewed by members of the Virtualbox Server
>>      Engineering team.
>>
>>    - All commits to stable branches are evaluated wrt. potential
>>      regressions and signed off by the Virtualbox team.
>>
>>    - Unit tests and regression tests are run on multiple platforms per
>>      push to the source code repository. In addition, there are more
>>      extensive test suites run daily and weekly.
>>
>>    - Each micro release receives extensive testing between code freeze
>>      and release. This includes the full functional test suite,
>>      performance regression testing, load and stress testing and
>>      compatibility and upgrade testing from previous micro and
>>      minor/major releases.
>>
>>    - Tests are run on all supported platforms (currently amd64 and i386).
> 
> This satisfies the current policy, so this looks fine for SRUing.
> 
> Martin
> 
>