From Fedora Project Wiki

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