[ << ] [ < ] [ Home ] [ > ] [ >> ]

2. AT Procedures

• Marking Stable: When and How?
• Marking a Package as Testing: What's the drill?

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.

[ << ] [ < ] [ Home ] [ > ] [ >> ]

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