summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--recruiters/quizzes/ebuild-quiz.txt205
-rw-r--r--recruiters/quizzes/end-quiz.txt175
-rw-r--r--recruiters/quizzes/staff-quiz.txt84
3 files changed, 464 insertions, 0 deletions
diff --git a/recruiters/quizzes/ebuild-quiz.txt b/recruiters/quizzes/ebuild-quiz.txt
new file mode 100644
index 0000000..884b4db
--- /dev/null
+++ b/recruiters/quizzes/ebuild-quiz.txt
@@ -0,0 +1,205 @@
+Ebuild development quiz
+Revision 1.12 - 19 January 2014
+Answer in whatever length necessary for completeness.
+Review documentation. Consult your mentor if you're unable to locate answers.
+
+*** Organizational structure questions
+
+1. When is it appropriate to post to the following mailing lists: gentoo-core,
+ gentoo-dev, gentoo-dev-announce, gentoo-project?
+
+docs: gentoo.org
+
+2. Who should be contacted with complaints about specific developers or
+ projects?
+
+docs: comrel policy
+
+3. What is the proper method for suggesting a wide-ranging feature or
+ enhancement to Gentoo? Describe the process for getting this feature
+ approved and implemented.
+
+docs: GLEPs
+
+4. What is the purpose of the Gentoo Council?
+
+docs: GLEPs
+
+5. What is the Gentoo Foundation? How does one apply for membership and
+ who are eligible?
+
+docs: gentoo.org
+
+6. What is the purpose of the Gentoo project structure?
+
+docs: GLEPs
+
+7. Who can start new Gentoo projects and how is it done?
+
+docs: GLEPs
+
+8. What is the purpose of herds?
+
+docs: devmanual
+
+9. What is the devaway system?
+
+docs: handbook
+
+
+*** Ebuild technical/policy questions
+
+1. You change a package's ebuild to install an init script. Previously,
+ the package had no init script at all.
+ Is a revision bump necessary? Why? What about when adding a patch?
+
+docs: devmanual
+
+2. A user submits a "live" VCS (git, svn ...) ebuild. What would be a preferable
+ alternative to such an ebuild?
+
+docs: handbook
+
+3. (a) What is repoman? How would you check for QA problems with
+ repoman?
+
+docs: handbook
+
+ (b) A user submits a brand-new ebuild for a new package. What are the
+ proper steps (including repoman/cvs commands) to take to add
+ this ebuild to the tree?
+
+docs: handbook
+
+4. A user submits an ebuild that has numerous technical problems and
+ violates policy. How would you handle that situation?
+
+docs: handbook
+
+5. You have a set of new ebuilds that could potentially benefit
+ from a global USE flag. What steps should be taken before
+ a new USE flag is implemented? What should be done if the
+ USE flag only applies to a single package?
+
+docs: devmanual
+
+6. What steps are needed to remove a use flag from IUSE in an ebuild?
+
+docs:
+
+7. You're creating an ebuild. Unfortunately, the ebuild's 'make install'
+ target causes numerous access violations. What is the best
+ course of action to take to have a clean, straightforward
+ ebuild?
+
+docs: devmanual
+
+8. You're creating an ebuild that needs a patch. The patch is
+ nontrivially large - bigger than 20kbytes. Where should
+ the patch be kept?
+
+docs: devmanual
+
+9. You're creating an ebuild that has its own license - one that
+ doesn't exist in /usr/portage/licenses/. What is the proper
+ course of action?
+
+docs: GLEPs, devmanual
+
+10. (a) You wish to have an ebuild marked "stable," taking it out of
+ ~ARCH KEYWORDS. It's a library. What steps should be taken to do so?
+
+docs: devmanual
+
+ (b) You wish to mark an ebuild "testing," putting it into ~ARCH
+ KEYWORDS. It was previously hard-masked in package.mask.
+ What should be done prior to doing so?
+
+docs: handbook
+
+ (c) You wish to have an ebuild marked "stable." It is a popular
+ application, but no other ebuilds depend on it.
+ What should be done first?
+
+docs: devmanual
+
+11. You're committing a user-submitted ebuild. What should be in the
+ initial ChangeLog?
+
+docs: devmanual
+
+12. What is the difference between DEPEND and RDEPEND?
+
+docs: devmanual
+
+13. You wish to make a change to an ebuild, but you checked
+ ChangeLogs and metadata.xml and it appears to be maintained by
+ someone else. How should you proceed?
+
+docs:
+
+14. You find a situation in which an eclass may be useful. What should
+ you do before implementing such an eclass?
+
+docs: devmanual
+
+15. How can you verify an ebuild has correct run time dependencies
+ (RDEPEND) for all installed binaries?
+
+docs: handbook
+
+16. How do you deal with a situation in which an ebuild wishes to
+ install a file already installed by another package?
+
+docs: handbook
+
+17. Most configure scripts attempt to automatically determine
+ settings based on the host system. When should the ebuild
+ specifically override settings?
+
+docs: devmanual
+
+18. What is EAPI?
+
+docs: devmanual, PMS
+
+19. What is the procedure for removing packages from the tree?
+
+docs: handbook
+
+20. How do keywording policies for less often used arches like ia64 or
+ mips differ from the more common ones like amd64?
+
+docs: devmanual
+
+21. You are adding a new major version to the tree that requires users to
+ follow an upgrade guide. How will you communicate this to the users?
+
+docs: GLEPs
+
+*** Please also submit the following information:
+
+* GPG public key ID (if you do not have one, please create one)
+ You should sign your quizzes with your key
+ http://www.gentoo.org/doc/en/gnupg-user.xml
+
+* SSH public key (if you do not have one, please create one)
+ http://www.gentoo.org/proj/en/infrastructure/cvs-sshkeys.xml
+ If you don't paste your key inline, make sure it's signed by your
+ gpg key.
+
+* Date of birth
+
+* Where do you live (Town/City, Country)
+
+* What are your programming/scripting skills, if applicable?
+
+* What other areas are you experienced in?
+
+* What other projects have you contributed to, if any?
+
+* Tell us about yourself. This doesn't need to be strictly
+ computer-relevant; things like where you're from,
+ hobbies, job, family, interests... This information will be used
+ for your public new developer announcement so please mention if
+ something should not be part of that.
diff --git a/recruiters/quizzes/end-quiz.txt b/recruiters/quizzes/end-quiz.txt
new file mode 100644
index 0000000..1df92a5
--- /dev/null
+++ b/recruiters/quizzes/end-quiz.txt
@@ -0,0 +1,175 @@
+Ebuild development (end of mentoring) quiz
+Revision 1.4.3 - 26 Aug 2013
+Answer in whatever length necessary for completeness.
+Review documentation. Consult your mentor if you're unable to locate answers.
+This quiz is based largely on ciaranm's bash quiz -- much thanks to
+him for the original and for extensive helpful feedback.
+
+1. You are writing an ebuild for the foomatic package. Upstream calls
+ the current version "1.3-7b" (but this is _not_ a beta release).
+ How would the ebuild be named? What's wrong with the ebuild
+ snippet below and how should this be written to aid
+ maintainability?
+
+ SRC_URI="http://foomatic.example.com/download/foomatic-1.3-7b.tar.bz2"
+ S=${WORKDIR}/foomatic-1.3-7b
+
+docs: devmanual
+
+2. You have a patch for foomatic which adds SSL support that is optional
+ at build time. Assuming that foomatic uses an autotools based build system
+ provide most probable changes required in an EAPI="0" ebuild. What should
+ be done for the ebuild in case it uses EAPI="5"?
+
+docs: devmanual
+
+3. What's the difference between local and global scope in an ebuild?
+
+docs: handbook
+
+4. Why should an external application (for example sed/grep) not be
+ called in global scope? What alternative methods can be used?
+
+docs: devmanual
+
+5. What is wrong with using $(somecommand) or `somecommand` or $ARCH
+ inside SRC_URI, DEPEND, etc?
+
+docs: devmanual
+
+6. Explain what's incorrect about the following code snippets and suggest
+ an alternative.
+
+6.a
+ # This ebuild doesn't like the -mcpu=ultrasparc CFLAG, so drop to v9
+ CFLAGS=${CFLAGS/-mcpu=ultrasparc/-mcpu=v9}
+
+docs: devmanual
+
+6.b
+ # Upstream don't support user-specified CFLAGS
+ unset CFLAGS
+
+docs: devmanual
+
+6.c
+ # Extra settings for when SSL is enabled
+ if [ "`use ssl `" ] ; then
+ # blah
+ fi
+
+docs: devmanual
+
+6.d
+ # Extra options for configure
+ use jpeg && myconf="--enable-jpeg" \
+ || myconf="--disable-jpeg"
+ use png && myconf="${myconf} --enable-png" \
+ || myconf="${myconf} --disable-png"
+ use gif && myconf="${myconf} --enable-gif89a" \
+ || myconf="${myconf} --disable-gif89a"
+ econf ${myconf}
+
+docs: devmanual
+
+6.e
+ # If we USE foo, we need to DEPEND upon libfoo. Unfortunately
+ # foo is completely broken on some archs
+ DEPEND="!x86? ( !amd64? ( !ppc? ( foo? ( >=dev-libs/libfoo-1.2 ) ) ) )"
+
+docs: devmanual
+
+6.f
+ # If USE=fnord is enabled, make extra targets:
+ use fnord && ( emake fnordification || die "it broke" )
+
+docs: devmanual
+
+7. Explain briefly the purpose of the following tools:
+ grep, cut, sed, cat, wc, awk
+
+docs: devmanual
+
+8. Why are 'head -5' and 'tail -5' bad? What should be used instead?
+
+docs:
+
+9. You're writing an ebuild and init script for a server application
+ that needs networking to be available when started and can also
+ use a system logger if one is available. How should this be
+ written in the init script?
+
+docs: devmanual
+
+10. What is the 'Gentoo Way' of allowing the user to pass other options
+ to the previously mentioned server application?
+
+docs: devmanual
+
+11. What is the 'Gentoo Way' of globally setting environment variables
+ for all users?
+
+docs: devmanual
+
+12. What directory should be used for application-generated
+ non-temporary data?
+
+docs: devmanual
+
+13. Which directory should manual (man) pages be in and how should they
+ be installed from an ebuild?
+
+docs: handbook
+
+14. On Gentoo Linux systems, what is the purpose of /usr/local/bin?
+
+docs: devmanual
+
+15. When should you use || die "msg" with commands/functions?
+ Could || die always be moved inside those functions/commands?
+
+docs: devmanual
+
+16. You are committing a new package to the tree. What will you have in
+ the KEYWORDS variable?
+
+docs: devmanual
+
+17. You are bumping foomatic's ebuild from version 1.2 to version
+ 1.3. The new release contains bugfixes and new
+ functionality. The current KEYWORDS for 1.2 are
+ "x86 sparc ~mips amd64" -- what will KEYWORDS be for
+ the new 1.3 ebuild?
+
+docs: devmanual
+
+18. You are bumping foomatic's ebuild from version 1.3 to 1.4. The
+ new release extends functionality and introduces a new
+ dependency on libfnord version 1.2 or later. The
+ KEYWORDS for foomatic-1.3 are "x86 sparc ~mips amd64"
+ and the KEYWORDS for libfnord-1.2 are "x86 ~sparc" --
+ what will you do?
+
+docs: devmanual
+
+19. You are bumping foomatic's ebuild from version 1.4 to 1.5. This
+ release introduces new optional support for the libgerbil
+ library, which you are controlling via the gerbil global
+ USE flag. Unfortunately libgerbil is full of code which
+ doesn't work properly on big endian systems, and so has
+ "-sparc -mips" in the KEYWORDS. How will you handle this?
+
+docs: devmanual
+
+20. You are bumping foomatic's ebuild from version 1.5 to version
+ 2.0. This new version is a massive rewrite which introduces
+ huge changes to the build system, the required libraries
+ and how the code works. What will you do for KEYWORDS here?
+
+docs: devmanual
+
+21. Your package only builds with newer gcc (e.g. >gcc-4.7).
+ How do you ensure that the user uses an appropriate compiler to build the
+ package? Under which circumstances should you avoid this check and how?
+
+docs: devmanual
diff --git a/recruiters/quizzes/staff-quiz.txt b/recruiters/quizzes/staff-quiz.txt
new file mode 100644
index 0000000..b7e294c
--- /dev/null
+++ b/recruiters/quizzes/staff-quiz.txt
@@ -0,0 +1,84 @@
+Non-ebuild staff quiz
+Revision 1.10 - 25 Spetember 2013
+Answer in whatever length necessary for completeness.
+Review documentation. Consult your mentor if you're unable to locate answers.
+
+*** Organizational structure & policy questions
+
+1. When is it appropriate to post to the following mailing lists: gentoo-core,
+ gentoo-dev, gentoo-dev-announce, gentoo-project?
+
+docs: gentoo.org
+
+2. Who should be contacted with complaints about specific developers or
+ projects?
+
+docs: comrel policy
+
+3. What is the proper method for suggesting a wide-ranging feature or
+ enhancement to Gentoo? Describe the process for getting this feature
+ approved and implemented.
+
+docs: GLEPs
+
+4. What is the purpose of the Gentoo Council?
+
+docs: GLEPs
+
+5. What is the Gentoo Foundation? How does one apply for membership and
+ who are eligible?
+
+docs: gentoo.org
+
+6. What is the purpose of the Gentoo project structure?
+
+docs: GLEPs
+
+7. Who can start new Gentoo projects and how is it done?
+
+docs: GLEPs
+
+8. What is the purpose of herds?
+
+docs: devmanual
+
+9. What is the purpose of ~ARCH?
+
+docs: devmanual
+
+10. Does a Gentoo user need to be aware of EAPI (justify)?
+
+docs:
+
+11. When should package.mask be used?
+
+docs: devmanual
+
+12. What is the devaway system?
+
+docs: developer handbook
+
+*** Please also submit the following information:
+
+* GPG public key ID (if you do not have one, please create one)
+ You should sign your quizzes with your key
+ http://www.gentoo.org/doc/en/gnupg-user.xml
+
+* SSH public key (if you do not have one, please create one)
+ http://www.gentoo.org/proj/en/infrastructure/cvs-sshkeys.xml
+
+* Date of birth
+
+* Where do you live (Town/City, Country)
+
+* What are your programming/scripting skills, if applicable?
+
+* What other areas are you experienced in?
+
+* What other projects have you contributed to, if any?
+
+* Tell us about yourself. This doesn't need to be strictly
+ computer-relevant; things like where you're from,
+ hobbies, job, family, interests... This information will be used
+ for your public new developer announcement so please mention if
+ something should not be part of that.