F9InstallationTesting
From FedoraProject
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
