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.p...@ubuntu.com>
A: "costamagnagianfra...@yahoo.it" <costamagnagianfra...@yahoo.it>
Cc: "technical-bo...@lists.ubuntu.com" <technical-bo...@lists.ubuntu.com>; 
"secur...@ubuntu.com" <secur...@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





--
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release

Reply via email to