Proposed Alpha criteria adjustments

Adam Williamson awilliam at redhat.com
Tue Jul 26 04:12:14 UTC 2011


On Fri, 2011-07-22 at 16:08 -0400, James Laska wrote:

>         The installer must be able to complete an installation using the
>         entire disk, existing free space, or existing Linux partitions
>         methods, with or without encryption enabled 
> 
> I propose the following minor adjustment to the above criteria:
> 
>         The installer must be able to complete an installation using the
>         entire disk, existing free space, or existing Linux partitions
>         methods, with or without encryption or LVM enabled.

ack!

> Any objections/corrections to the following Alpha criteria addition to
> cover the reboot/shutdown use case?
> 
>         The systems' mechanisms for shutting down, logging out and
>         rebooting from a virtual console must work

s,systems',system's,g

I think we don't really need reboot to work; shut down and then turn
back on is a fine workaround at Alpha phase. If there was a bug in
rebooting, but shutting down worked, I'd probably not want that to be an
Alpha blocker. And since we're interested in the mechanics of shutting
down here, I'd like to be a bit more specific about what we mean by
'work' (it's a less problematic concept when we're just talking about
*triggering* a shutdown). So, how about:

It must be possible to trigger a system shutdown using standard console
commands, and the system must shut down in such a way that storage
volumes (e.g. simple partitions, LVs and PVs, RAID arrays) are taken
offline safely and the system's BIOS or EFI is correctly requested to
power down the system

This covers the most important thing about shutdown (clean unmount) but
lets us not consider, say, one service not correctly going down to be a
blocker. It also gets around any case where we send a proper shutdown
trigger but there's a BIOS/EFI bug that causes the system not to
actually power off. (It's kind of debatable whether we actually care
about the system powering off, or if we just want to make sure storage
off line).

There's a possibility we might want a more stringent requirement at
Final - say, standard services should power down properly - but I'm not
sure about that; we have a criterion for bugs that may cause data loss
or corruption, and I think that's the only really bad possible
consequence of improper service shutdown. But it's worth considering.

We also need a test case for this, of course.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net



More information about the test mailing list