F9InstallationTesting

Attending: Max Spevack, Russell Harrison, James Laska, Chris Lumens, John Poelstra, Doug Newcomb, Brock Organ, Matt Domsch, Peter Jones

Minutes: Brock Organ

Minutes

• Introductions
• Secondary Arch: Mainframe/System z availability
• Brock: Red Hat has resources, would like to make some publically available
• Brock will check with Red Hat internal IS/IT folks for accessibility
• James: Fedora9 Installation Test Plan
• John: will test plan cover entire campaign? How do milestones fit?
• Chris: any "public deliverable" release should have testing
• Chris: priority is to test "common" use cases, install paths
• Where does LiveCD fit?
• Max: What is plan for adding features to LiveCD?
• Chris: path to test is the "Install" feature of the LiveCD
• because of the stage2.img differences (between normal installation and LiveCD installation) it is important to test both
• LiveCD vs LiveUSB?
• John: CDROM releases are coming back (for F9)
• Chris: kudzu is removed, replaced by udev/HAL
• Russell: LiveCD install can be intimidating for users because of partitioning
• Chris: improvements make resizing possible
• edited No More Kudzu
• edited Support Creation of Encrypted Block Devices within Anaconda
• edited First Aid Kit
• Chris: want more internationalization testing
• often, users don't find devastating i18n bugs until after release
• Start a list of people interested in verifying i18n for different geographies
• Doug: problem partitioning > 2 Tb disks
• Chris: lack of hardware (generally)
• John: get the word out (list), someone in community can test
• Russell: A simple page of general instructions for testing each of the cases
• Russell: also, an "ad hoc" testing page
• Doug: maybe page could have comments so people could add information
• John: interested in dedicated Fedora Installation meeting.
• Brock: weekly?
• Russell: prefer bi-weekly or monthly
• Chris: How involve more people?
• Huge test plan, small number of people
• John: important to provide "where to start" page/location
• Russell: could have many pages, each page with tracking for results
• Matt: long term, need to meld large test plan efficiently among interested community members
• Peter: need triaging software (such as auto-dup)
• Matt: can virtualization help for test cases that don't require physical hardware?
• James: SNAKE (smart network automated kickstart environment)
• goals: map templates to testcases (and automate the testing)
• provide api to access tree information
• Matt: hard drive installs are important
• no scheduler yet in SNAKE
• Peter: consider liveCD creator, creates a liveCD that executes the test
• Peter volunteers Chris to implement it
• Chris: test exception reporting mechanism (able to save and report tracebacks, errors)
• James: starting a test plan section for recovery scenarios
• James: for centralizing the test results reporting would something like smolt be good?
• What debugging information is useful for filing bug report?
• Matt: file sysreport
• Peter: anacdump.txt provides most information (except lvm)
• Matt: When anaconda fails, want to have enough info for anaconda developers, kernel developers have enough info for resolution without having to go back and ask for more information
• what hardware was tested?
• what tree was tested?
• Chris: there is a resource page for this (See Effective anaconda bug reporting )
• Russell: adding additional repos to kickstart can have depsolving issues
• but this can leave a broken system if partitioning is committed before package selection
• Chris: maybe abilities to better handle repo issues

Action Items:

• bi-weekly meetings?
• John: no, instead use existing list, fedora-test-list
• Matt: have resources available to help with F9 test cases