On Mar 13, 2014, at 8:50 PM, Adam Williamson <awill...@redhat.com> wrote: > > What does everyone think? Thanks!
Device tests: -PATA? They aren't made anymore, do we really need to distinguish between SATA and PATA? Is there a case where it worked on one but not the other? I'd think we'd sooner want SATA vs SAS, at least they use a different driver. - I'm not sure how to do a one line categorization of PCI Express storage. But it seems like we ought to have one, for now since there are products. And then figure out how it all relates with SATA Express and NVMe, and whether those will need separate device tests or if they're collapsable. ------------- Volume type tests: Guided installation Alpha QA:Testcase_partitioning_guided_empty tests blank drive without partition map, should confirm whether MBR/GPT is used in the right case Alpha QA:Testcase_partitioning_guided_delete_all tests delete all button and ability to make a populated disk "empty" Beta QA:Testcase_partitioning_guided_delete_partial tests delete button, makes populated-disk have "free space" Beta QA:Testcase_partitioning_guided_encrypted_empty Does this need to be empty? Or can it be "encrypted_any"? Seems like the target could be empty, delete_all, delete_partial, or freespace. The code path is the same, in that it must create a partition, encrypt it, make the dmcrypt device a PV, add it to a VG, make LVs from that. Therefore I think the encryption outcome is tested if we do any other test also. Beta QA:Testcase_partitioning_guided_multi_empty What is this? Beta QA:Testcase_partitioning_guided_free_space Partially populated drive with freespace, so this is an existing partition map with at least one entry, and also sufficient free space for a Fedora installation (could be existing Linux, OS X, Windows, with free space already set aside prior to arriving in anaconda). --------- Custom partitioning - encrypted_empty_auto vs encrypted_empty_manual; doesn't seem to test a different code path because we don't have this inheritance of the encrypted checkbox since Installation Options dialog is vanquished. - What we do have a meaningful difference in custom partitioning encryption, is that it's possible to encrypt a whole PV/VG, vs encrypting individual LVs. And implicitly we'd want to make sure the user can't encrypt both at the same time (a bug that I think got fixed in F20 but was present in F19). This an LVM/LVMthinp test only though. Nothing else permits double encryption. - What is QA:Testcase_partitioning_custom_existing_precreated? Layout created elsewhere and this tests the ability of the installer to use that without making changes? Basically assigning mount points to existing? Needs a RAID column I think, if we're going to test the anaconda supported "create raid elsewhere" and use it in anaconda workflow. - Seems like in general we need more RAID tests. I don't see a hardware raid test. Or any explicit software raid0, raid1, raid10, raid4 (a.k.a. nutcase), raid5 or raid6 tests. Should there be a separate software raid matrix section? And should the matrix show only what we want to "support/test"? Or only those we'd block on? Or all possible checkboxed options, and subjectively list some of them as "bonus" release level, rather than alpha/beta/final? - ext2 and ext3. I think these should be bonus, or even removed from the test matrix. Yes they're visible in the installer (which I disagree with), therefore they should work, and if they don't I'd consider it a blocker bug. But how many file system choices do we need on Linux? And how many do we need to test? It's appealing to the Smörgåsbord installer mentality which I think is in the realm of OCD please go hire a shrink. Anything ext2/3 can do ext4 can do better and if it can't it's a bug. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
