Gentoo/PPC Testing Docs

Content:

• Gentoo/PPC Testing Docs
  Provides testing documentation for Gentoo/PPC users.
  1. Gentoo/PPC Arch Testers
     This explains what arch testing involves and how it relates to core Gentoo/PPC efforts.
  2. AT Procedures
     This document explains the formal procedures involved in arch testing for PPC, including applications.

A. Gentoo/PPC Testing Docs

1. Gentoo/PPC Arch Testers

1.a. PPC Arch Testers Information

Gentoo/PPC will maintain a pool of "Arch Testers" (ATs) and one or more PPC Developers will take the responsibility of managing the AT group. ATs will be included on the ppc@gentoo.org alias, so they can be informed of all bug activity. The current AT head for PPC is Joseph Jezak. Any problems, suggestions and/or flames should be directed at him.

ATs will be responsible for responding to all test requests in a timely manner (including keywording, security, marking stable, requests from devs on irc, etc...) and ensuring that the application works, as well as check that the ebuild doesn't contain any glaring errors. ATs must keep their system up to date, use reasonable CFLAGS, and keep with the current profile. When marking a bug as tested all ATs will use the keyword "TESTED" in bugzilla (in the "keywords" field)

Gentoo/PPC developers will be able to take ATs word at their own discretion since ultimately, committing the requested changes will be the dev's responsibility . Feel free to ask for more than one tester if you feel the bug warrants it.

Prospective AT's will have to pass the ebuild quiz. Additionally, all quizes should be submitted to the PPC AT leader and hparker (who has graciously volunteered to mentor potential PPC ATs).

A note about arch testers "status": Gentoo/PPC Arch Testers are not official Gentoo developers. They are, however, a recognized part of the Gentoo/PPC arch team. All AT's should keep this in mind when selecting email signatures or other forms of communication.

2. AT Procedures

2.a. Marking Stable: When and How?

There are lists which show packages with the ppc keyword lagging behind the x86 keyword and need to be tested -- and eventually marked stable. If you want access to such a list, please ask a Gentoo/ppc developer. It's very useful to have people systematically testing these packages - it helps to keep ppc packages as up-to-date as possible. The following guidelines are specifically aimed at Gentoo/PPC Arch Testers (ATs) doing testing.

• Check to ensure the latest version of the package is marked ~ppc (TESTING), and if not, please read the next section of the document for the steps to for quickly and efficiently having a package keyworded ~ppc.
  
  
• If the package is already ~ppc:
  • Check to see when the package was marked ~ppc. There should be a date in the package Changelog, but if there isn't one, please use the ViewCVS functionality on http://viewcvs.gentoo.org to look for the date it was keyworded ~ppc. If it was less than 30 days ago, the package is not yet eligible for a stable marking, but testing and feedback are still greatly appreciated.
  • Check for bugs on this particular version of the package. If a bug has been opened in the last 30 days, it is not eligible.
  • If it has been in testing for more than 30 days, and has not had an open bug in the last 30 days, you need to test it in a thorough and systematic manner. Every conceivable permutation should be checked and rechecked - if it breaks you need to go onto Bugzilla and open a relevant bug. If it doesn't break and you are totally satisfied it's stable, continue to the final step -- but beware, its your responsibility if this package breaks!
  • Assuming it meets all the criteria (tested for 30+ days, no bugs in the last 30 days, AT tested) you may open a bug with the title '<category>/<package>-<version> is stable on PPC'. Assign the bug directly to ppc@gentoo.org to avoid making more work for the overworked Bug Wranglers. You should include the output of your 'emerge info' and keyword the bug STABLE.
  • Wait for a developer to review the bug, and mark the package stable.

2.b. Marking a Package as Testing: What's the drill?

In some cases the late file may show packages where the latest version is not yet ~ppc, or a new and popular package needs to be keyworded ~ppc. In these cases, we need to have them 'marked testing' - so when they're bug free for thirty days they can be made stable.

• Check that the package hasn't already got any open bugs regarding it being marked testing. Quite often users will let us know about popular packages needing a keyword before any devs/ATs even notice!
• If the package doesn't have a bug yet:
  • Check to see whether previous versions of the package were in testing or stable on PPC.
    • If the previous version was keyworded and this is a minor version increment
      Check the Changelog for the version increment, install the package and test any new, improved or otherwise modified features. Check the install proceeds smoothly, all of the intended functionality is present and there are no glaringly obvious bugs. If you see any bugs, file them on Bugzilla and when they're resolved test again. If everything works as expected, proceed to putting in the ~ppc request.
    • If the previous version was keyworded and this is major version increment
      Check the Changelog, install the package and test all the new and improved features. Check for bugs in previous versions, see if they have been fixed and be especially careful to see whether new ones crept in with the new code. Test all the other functionality, even functionality which you think will work - a major version increment means a lot of changes, and it's treated almost like a new addition to the tree - everything has to be tested and verified. If everything works as expected, proceed to putting in the ~ppc request.
    • If it's a new package which hasn't been keyworded before
      Anything which has never been keyworded for ppc before is a little more tricky to process. You don't have a nice Changelog to refer to for a list of things to test, a previous version which worked to use as reference or much other help. You need to install the package and then test thoroughly:
      
      1. The package should install without errors and be ready to run out of the box with minimal effort on the part of user.
      2. Major functionality should all work with no significant errors. Minor errors like a typo are probably acceptable, but should be noted. It's understood that you can't go through every operation possible, but it should work in an acceptable manner for day-to-day usage by a user.
      3. The package shouldn't break anything that depends on it. This is especially important for libraries. Make sure to test programs that depend on or use your program to ensure that marking this package will not break other packages.
      
      Assuming the package installs, loads and works with no major errors, proceed to putting in the ~ppc request.
    
    
  • Assuming your testing efforts went well, and all procedures were followed, you are now ready to open a bug so a PPC dev can commit the change.
    
    • Open a bug with '<category>/<package>-<version> is TESTED on PPC' as the title. Assign the bug a keyword: TESTED
    • Assign the bug directly to ppc@gentoo.org to avoid overworking the Bug Wranglers as well as to let the ppc team know of the new bug.
    • Include a short description of the package, what you've tested and your 'emerge info'. Explicitly specify that you wish the ~ppc keyword to be added to the package's keywords.
    • Get to work on another package and a PPC dev will resolve your bug as soon as possible.

The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license.