diff options
Diffstat (limited to 'xml/htdocs/proj/en/base/x86/arch-testers-faq.xml')
| -rw-r--r-- | xml/htdocs/proj/en/base/x86/arch-testers-faq.xml | 459 |
1 files changed, 459 insertions, 0 deletions
diff --git a/xml/htdocs/proj/en/base/x86/arch-testers-faq.xml b/xml/htdocs/proj/en/base/x86/arch-testers-faq.xml new file mode 100644 index 00000000..f6a14045 --- /dev/null +++ b/xml/htdocs/proj/en/base/x86/arch-testers-faq.xml @@ -0,0 +1,459 @@ +<?xml version='1.0' encoding="UTF-8"?> + +<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> + +<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/x86/arch-testers-faq.xml,v 1.27 2010/08/12 08:32:49 fauli Exp $ --> + +<guide link="/proj/en/base/x86/arch-testers-faq.xml"> +<title>Gentoo x86 Arch Tester's FAQ</title> + +<author title="Author"> + <mail link="halcy0n@gentoo.org">Mark Loeser</mail> +</author> +<author title="Editor"> + <mail link="fox2mike@gentoo.org">Shyam Mani</mail> +</author> +<author title="Editor"> + <mail link="fauli@gentoo.org">Christian Faulhammer</mail> +</author> + +<abstract> +This document is the x86 Arch Tester's bible. +</abstract> + +<!-- The content of this document is licensed under the CC-BY-SA license --> +<!-- See http://creativecommons.org/licenses/by-sa/2.5 --> +<license/> + +<version>1.7</version> +<date>2010-08-12</date> + +<chapter> +<title>Introduction</title> +<section> +<body> + +<p> +This FAQ attempts to answer the most commonly asked questions about being an +Arch Tester with the x86 team. Questions can be asked on irc at #gentoo-x86 or +mailed to the Author. +</p> + +</body> +</section> +</chapter> + +<chapter> +<title>Questions</title> +<section> +<title>The Basics</title> +<body> + +<p> +General queries regarding Arch Testing. +</p> + +<ul> + <li><uri link="#whoat">Who is an Arch Tester?</uri></li> + <li><uri link="#whyat">Why does Gentoo need Arch Testers?</uri></li> + <li> + <uri link="#basicsk">What are the basic skills I need to be an AT?</uri> + </li> + <li> + <uri link="#basicsys">What are the basic system requirements if + any?</uri> + </li> + <li> + <uri link="#x86at">What does it mean to be part of the x86 AT + Team?</uri> + </li> + <li> + <uri link="#atwhat">What do I have to do as an AT? What are my + roles/responsibilities?</uri> + </li> + <li> + <uri link="#athow">How do I get involved with the team and start + helping out?</uri> + </li> +</ul> + +</body> +</section> +<section> +<title>Getting Ready</title> +<body> + +<p> +How to get your system setup and ready to test packages. +</p> + +<ul> + <li> + <uri link="#stchroot">I don't run stable x86, my box is ~x86. How can I setup + an x86 chroot?</uri> + </li> + <li> + <uri link="#kernelv">I run an unstable kernel. Would that be an issue when + I'm testing packages?</uri> + </li> +</ul> + +</body> +</section> +<section> +<title>Work Work Work!!!</title> +<body> + +<p> +Stuff that you do on a day to day basis. +</p> + +<ul> + <li> + <uri link="#steptest">What are the steps I need to follow when I'm + testing a package?</uri> + </li> + <li><uri link="#powers">What godly powers do I have as an AT?</uri></li> + <li><uri link="#whomct">Whom do I contact in case of breakages?</uri></li> + <li> + <uri link="#methct">What are the best ways of contacting + maintainers/devs?</uri> + </li> +</ul> + +</body> +</section> +</chapter> + +<chapter> +<title>The Basics</title> +<section> +<body> + +<p> +This section aims to be quite generic and questions answered here hold true +across most archs in Gentoo. +</p> + +</body> +</section> +<section id="whoat"> +<title>Who is an Arch Tester?</title> +<body> + +<p> +An Arch Tester (commonly referred to as "AT") is a trustworthy user capable of +testing an application to determine its stability. To be an AT you must be able +to test a wide array of packages, and be able to understand and modify ebuilds. +</p> + +</body> +</section> +<section id="whyat"> +<title>Why does Gentoo need Arch Testers?</title> +<body> + +<p> +We need ATs to help improve Quality Assurance (QA), and to help Arch Devs ensure +packages are actually stable by having it tested by others whom report their +findings. As the tree gets larger and larger we will need more people to +actively watch for things that break, and help get them fixed. +</p> + +</body> +</section> +<section id="basicsk"> +<title>What are the basic skills I need to be an AT?</title> +<body> + +<p> +You should be able to modify ebuilds and recognize mistakes that should be +corrected before we mark the package stable. It is also expected that you can +test packages and give good bug reports if there are problems with anything. +This means you should be comfortable with bash scripting as well as Gentoo +specific areas such as Portage overlays. +</p> + +</body> +</section> +<section id="basicsys"> +<title>What are the basic system requirements if any?</title> +<body> + +<p> +You'll need a system or chroot, which only uses packages marked +"x86". This is so we actually use stable libraries to test packages +against, and can find bugs in packages marked stable. Alternatively +you can run Gentoo on a dedicated machine for testing only or in a +virtual machine. Suitable programs for the latter are VirtualBox, +VMWare or QEmu/KVM, although its use for architecture work is +discouraged because it does not run on actual hardware. +</p> +<p> +Additionally you should set <c>FEATURES="test collision-protect"</c> +to catch test failures and file collisions between packages. Some +packages do not respect the values of LDFLAGS and CFLAGS/CXXFLAGS when +building, which can lead to breakage. So you should at least set +<c>LDFLAGS="${LDFLAGS} -Wl,--hash-style=gnu"</c>, which makes Portage +output a warning about it. +</p> +</body> +</section> + +<section id="x86at"> +<title>What does it mean to be a part of the x86 AT Team?</title> +<body> + +<p> +Being part of the x86 AT Team means you are prepared to dedicate some amount +of time to help Gentoo/x86. It also means that you are interested in helping +test any applications we are asked to mark stable. +</p> + +</body> +</section> +<section id="atwhat"> +<title>What do I have to do as an AT? What are my +roles/responsibilities?</title> +<body> + +<p> +You need to help arch devs test packages. Testing a package requires more +than just ensuring it compiles. It is expected that you will ensure that +atleast major functionality works in the application. When testing a package, +ensure you have <c>FEATURES="test collision-protect"</c> on. If any package fails to +emerge with this feature set, it is a major QA issue and we can't proceed +until it's resolved. +</p> + +</body> +</section> +<section id="athow"> +<title>How do I get involved with the team and start helping out?</title> +<body> + +<p> +First you should read this entire FAQ so you are familiar with what being an +AT actually means. After completing that, you should come on irc.freenode.net +and hang out in #gentoo-x86. Developers often ask for help with testing a +package, and you can try helping out wherever you can. +</p> + +<p> +The main way for you to start helping out is to look at our bugs. Here are a +few links for you bookmark or save as searchs on bugzilla: +</p> + +<ul> + <li> + <uri link="http://tinyurl.com/obcta">All x86 bugs</uri> + </li> + <li> + <uri link="http://tinyurl.com/cpdjk">Security related x86 bugs</uri> + </li> +</ul> + +<p> +Finally, after you have shown some level of commitment and we believe you +will be a good addition to the team, we will give you the +<uri link="http://www.gentoo.org/proj/en/devrel/quiz/ebuild-quiz.txt">ebuild +quiz</uri> and then there will be a 30 day mentoring period. +</p> + +</body> +</section> +</chapter> + +<chapter> +<title>Getting Ready</title> +<section> +<body> + +<p> +This section deals with commonly asked "how to setup" style questions to guide +you through getting your system ready to do some AT work :) +</p> + +</body> +</section> +<section id="stchroot"> +<title>I don't run stable x86, my box is ~x86. How can I setup an x86 +chroot?</title> +<body> + +<p> +Please take a look at the <uri link="chroot.xml">Chroot Guide</uri> for more +information regarding setting up a chroot environment. +</p> + +</body> +</section> +<section id="kernelv"> +<title>I run an unstable kernel. Would that be an issue when I'm testing +packages?</title> +<body> + +<p> +It is preferred that you use a stable kernel outside of the chroot but it is +not a firm requirement. +</p> + +</body> +</section> +</chapter> + +<chapter> +<title>Work Work Work!!!</title> +<section> +<body> + +<p> +Questions on how exactly to go about doing your work on a daily basis are +answered here. +</p> + +</body> +</section> +<section id="steptest"> +<title>What are the steps I need to follow when I'm testing a package?</title> +<body> + +<ol> + <li>Ensure that all packages in the system/chroot are stable.</li> + <li> + Set <c>FEATURES="test collision-protect"</c> in + <path>/etc/make.conf</path> and use a "sane" set of <c>CFLAGS</c>, + as described in the <uri + link="http://www.gentoo.org/doc/en/gcc-optimization.xml">Compilation + Optimization Guide</uri>. + </li> + <li> + Choose a request from the above-mentioned bug lists, where + security bugs and keywording requests have absolute priority. + </li> + <li> + Normally, all needed packages are listed in the request, but + sometimes, dependencies are forgotten. This is usually no + problem for most things, but you should include it in your report + nonetheless. To automatically add all needed packages to the + <c>package.keywords</c> file, you may use <uri + link="http://packages.gentoo.org/package/app-portage/gatt">app-portage/gatt</uri>. + </li> + <li> + After merging the package with various USE flag combinations, run + it and ensure that basic functionality works. If the package is a + library, emerge a couple of packages that use the library to + ensure they still work with the new version (best option: all that + depend on it and have a stable version). The so-called + reverse-dependencies are found in the <uri + link="http://tinderbox.dev.gentoo.org/misc/dindex/">dindex</uri>. + </li> + <li> + Inform the team about the successful test or the occured failures + on the corresponding bug report including what you did and on + what platform. If there were problems, add your <c>emerge + --info</c> output, too. + </li> + <li> + Problems that occur in the currently stable version, too, will + not always be an obstactle to stabilisations, but need to be + reported nonetheless. + </li> +</ol> + +<p>Additional hints you may find useful:</p> + +<ul> + <li> + Architecture testers not only test packages but also seek + actively for solutions were problems occured. Important sources + of information are version control systems and bug trackers of + other distributions and also upstream. Reporting bugs to the + authors is as important as testing packages! + </li> + <li> + Set a user watch for Bugzilla in your <uri + link="http://bugs.gentoo.org/userprefs.cgi?tab=email">preferences</uri> + on the x86@gentoo.org alias. Thus you will receive all mails + from Bugzilla directed towards the x86 team. + </li> +</ul> + +</body> +</section> +<section id="powers"> +<title>What godly powers do I have as an AT?</title> +<body> + +<p> +Hah. You were joking when you asked that right? AT's are minions who do all the +work and have no powers or play......okay, I was kidding :) +</p> + +<p> +Things you have access to/can do as an AT: +</p> + +<ul> + <li> + Elevated priviledges on <uri link="http://bugs.gentoo.org">Gentoo + Bugzilla</uri> so that you can modify all aspects of a bug. This is mainly + given so that you can re-assign bugs correctly in case needed and + co-ordinate with package maintainers/other arch teams etc. + </li> + <li>Read-only cvs access to the gentoo-x86 repository, which is not + a privilege, but may come in handy for ATs. See <uri + link="http://sources.gentoo.org/">ViewCVS</uri> for a checkout URL + for anonymous access.</li> +</ul> + +<p> +Things you don't have access to/can't do as an AT: +</p> + +<ul> + <li> + Commit fixes for ebuilds. You'll have to find the maintainer or another + developer with access to do that for you. + </li> +</ul> + +</body> +</section> +<section id="whomct"> +<title>Whom do I contact in case of breakages?</title> +<body> + +<p> +If you notice some major breakage in the tree, first try to contact the person +that caused the breakage. This can be found in the <path>ChangeLog</path> +normally, but if not, use <uri link="http://sources.gentoo.org/">ViewCVS</uri> +to see who committed the change. If you can't get in touch with this person, try +the maintainer or herd of the package (if the maintainer is not the same person +that caused the breakage). If all else fails, make an x86 dev aware of the +situation so we can address it as best as we can until someone is available to +address it properly. +</p> + +</body> +</section> +<section id="methct"> +<title>What are the best ways of contacting maintainers/devs?</title> +<body> + +<p> +Normally the easiest way to contact a dev is to "ping" them on IRC. If they +aren't around on IRC, send them an email. If you are unable to get in touch +with them, try contacting someone else in the herd (if applicable). If there +is no herd to get in touch with then tell someone in the x86 team what the +issue is and we'll figure out how to proceed. Also, unless the problem is +severe, give them enough time to respond back through email. Do check the +<uri link="http://dev.gentoo.org/devaway/">devaway</uri> to make sure the +person you're trying to reach isn't away. +</p> + +</body> +</section> +</chapter> +</guide> + |