Gentoo x86 Arch Tester's FAQThis 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. General queries regarding Arch Testing.
How to get your system setup and ready to test packages.
Stuff that you do on a day to day basis.
This section aims to be quite generic and questions answered here hold true across most archs in Gentoo. 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. Why does Gentoo need Arch Testers? 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. What are the basic skills I need to be an AT? 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. What are the basic system requirements if any? 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. What does it mean to be a part of the x86 AT Team? 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. What do I have to do as an AT? What are my roles/responsibilities? 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 FEATURES="collision-protect" 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. How do I get involved with the team and start helping out? 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. 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: 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 ebuild quiz and then there will be a 30 day mentoring period. This section deals with commonly asked "how to setup" style questions to guide you through getting your system ready to do some AT work :) I don't run stable x86, my box is ~x86. How can I setup an x86 chroot? Please take a look at the Chroot Guide for more information regarding setting up a chroot environment. I run an unstable kernel. Would that be an issue when I'm testing packages? It is preferred that you use a stable kernel outside of the chroot but it is not a firm requirement. Questions on how exactly to go about doing your work on a daily basis are answered here. What are the steps I need to follow when I'm testing a package?
What godly powers do I have as an AT? 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 :) Things you have access to/can do as an AT:
Things you don't have access to/can't do as an AT:
Whom do I contact in case of breakages? 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 ChangeLog normally, but if not, use ViewCVS 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. What are the best ways of contacting maintainers/devs? 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 devaway to make sure the person you're trying to reach isn't away. The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license. |
|
