diff options
Diffstat (limited to 'xml/htdocs/proj/en/base/amd64/at/procedures.xml')
| -rw-r--r-- | xml/htdocs/proj/en/base/amd64/at/procedures.xml | 205 |
1 files changed, 205 insertions, 0 deletions
diff --git a/xml/htdocs/proj/en/base/amd64/at/procedures.xml b/xml/htdocs/proj/en/base/amd64/at/procedures.xml new file mode 100644 index 00000000..45bd936d --- /dev/null +++ b/xml/htdocs/proj/en/base/amd64/at/procedures.xml @@ -0,0 +1,205 @@ +<?xml version='1.0' encoding="UTF-8"?> +<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> + +<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/amd64/at/procedures.xml,v 1.5 2009/09/06 04:54:46 darkside Exp $ --> + +<!-- The context of this document is licensed under the CC-BY-SA license --> +<!-- See http://creativecommonds.org/licenses/by-sa/1.0 --> + +<guide link="/proj/en/base/amd64/at/procedures.xml" lang="en"> +<title>Gentoo/AMD64 Arch Testers' Guide</title> + +<author title="Author"> + <mail link="hparker@gentoo.org">hparker@gentoo.org</mail> +</author> + +<abstract> +This Guide shows you how to test packages for stablization/inclusion into the testing tree. +</abstract> + +<license/> + +<version>1.2</version> +<date>2006-09-27</date> + +<chapter> +<title/> +<section> +<title>Marking Stable: When and How?</title> +<body> + +<p> +The <uri link="http://dev.gentoo.org/~darkside/perm/imlate.txt">imlate</uri> +file is there to show which packages on amd64 are lagging +behind on x86 and need to be tested and eventually marked stable. It's +very useful to have people systematically testing these packages - it +helps to keep amd64 as up-to-date as possible. The following guidelines +are specifically aimed at Gentoo/AMD64 Arch Testers (ATs) doing testing. +</p> + +<ul> +<li> + Check the newest version of the package is marked ~amd64 (TESTING), + if not please read the next section of the document for the steps + to follow to quickly/efficiently have a package keyworded ~amd64. + <br/><br/> +</li> + +<li> + If the package is already ~amd64, then: + <ul> + <li> + Check to see when it was marked ~amd64. There should be a date + in the package changelog, but if there isn't please use the + ViewCVS functionality on http://sources.gentoo.org to look for + the date it was keyworded ~amd64. If it was less than 30 days + ago, the package is not eligible to be marked stable, but + testing and feedback are still greatly appreciated. + </li> + <li> + Check for bugs on this particular version of the package. If a + bug has been open in the last 30 days, it is not eligible. + </li> + <li> + 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 relevent bug. If it doesn't break and + you are totally satisfied it's stable, continue to the final + step -- but beware, its your head if this package breaks! + </li> + <li> + 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 AMD64'. + Assign the bug directly to amd64@gentoo.org to avoid making + more work for the poor Bug Wranglers. You should include the + output of your 'emerge --info' and keyword the bug <c>STABLE</c>. Just + wait a while, a developer will review the bug, and mark stable. + </li> + </ul> +</li> +</ul> + +</body> +</section> + +<section> +<title>Marking Testing: What's the drill?</title> +<body> + +<p> +In some cases the imlate file may show packages where the latest version is +not yet ~amd64, or a new and popular package needs to be keyworded ~amd64. In +these cases, we need to have them 'marked testing' - so when they're bug free +for thirty days they can be made amd64 stable. +</p> + +<ul> +<li> + Check the package hasn't already got any open bugs regarding it being + marked testing. Quite often users will prod us about popular packages + needing a keyword before any devs/ATs even notice ;)<br/><br/> +</li> + +<li> + If the package doesn't have a bug yet, go ahead and start:<br/><br/> + <ul> + <li> + Check to see whether previous versions of the package were in + testing or stable on AMD64. If the version increment is only a + minor one (1.4.0 to 1.4.1) and previous version was stable, it's + slightly different to where a package has had a major version + increment or has never been ~amd64/amd64.<br/><br/> + <ul> + <li> + <b> + Previous version keyworded, minor version increment</b><br/> + Check the changelog for the version increment, install the package + and test any new, improved or otherwise modified features. Check + the install is smooth, everyday functionality is there 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 seems + okay, proceed to the final stage (putting in the ~amd64 request). + </li> + <li> + <b>Previous version keyworded, major version increment</b><br/> + 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 all the new code. Test all the other functionality, + even stuff 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 you're + happy it seems to be running okay, proceed to the final stage. + </li> + <li> + <b>New package, not keyworded before</b><br/> + Anything which has never been amd64 keyworded 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:<br/><br/> + <ol> + <li> + Package should install without errors and be ready to run + 'out of the box' with minimal effort on the part of user. + </li> + <li> + Major functionality (which isn't hard to test) should all + work with no significant errors. Minor errors like a typo + are probably acceptable, and we understand you can't go + through every operation possible, but it should work in + an acceptable manner for day-to-day usage by a user. + </li> + <li> + Package shouldn't break anything related... + </li> + </ol><br/> + Assuming it installs, loads and works pretty well with no major + errors - please proceed to the final step and congratulate your + computer on adding yet another package to the expanding arsenal! + </li> + <li> + <b>Package requires patches that are in bugs.gentoo.org</b><br/> + Make a comment in your bug stating that these patches fix issues + with the package, and CC the maintainer of the package. Developers + will then wait 7-30 days to commit if maintainer does not handle + the bug. The types of patches in this category include: arch + specific patches, multi-lib strict, etc. + </li> + </ul> + <br/> + </li> + + <li> + Assuming your testing efforts above went well, and all procedures were + followed, you are now ready to open a bug and metaphysically prod a dev + into committing the change. + <br/><br/> + <ul> + <li> + Open a bug with '<category>/<package>-<version> is TESTED on AMD64' + as the title. Assign the bug a keyword: TESTED + </li> + <li> + Assign the bug directly to amd64@gentoo.org - saves giving those + Bug Wranglers yet another grey hair on their already snowy heads. + </li> + <li> + Include a short description of the package, what you tested and + your 'emerge info'. Explicitly specify you wish the ~amd64 to be + added to the keywords, it helps us grumpy old developers focus + at 3am in the morning when sleep is probably a good idea ;) + </li> + <li>Sit back and wait, someone will resolve the bug ASAP.</li> + </ul> + </li> + </ul> + </li> +</ul> +</body> +</section> +</chapter> +</guide> |