end-quiz: Combine KEYWORDS questions into a single number

They are quite related, so it seems more reasonable to have them
combined. Furthermore, it reduces the apparent question number!

1 files changed, 29 insertions, 29 deletions

diff --git a/recruiters/quizzes/end-quiz.txt b/recruiters/quizzes/end-quiz.txt
index 14b5df5..7e1c1aa 100644
--- a/recruiters/quizzes/end-quiz.txt
+++ b/recruiters/quizzes/end-quiz.txt
@@ -133,64 +133,64 @@ docs: devmanual
 
 docs: devmanual
 
-15. You are committing a new package to the tree. What will you have in
-    the KEYWORDS variable?
+15.a. You are committing a new package to the tree. What will you have in
+      the KEYWORDS variable?
 
 docs: devmanual
 
-16. 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?
+15.b. 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
 
-17. 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?
+15.c. 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
 
-18. 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?
+15.d. 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
 
-19. 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?
+15.e. 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
 
-20. Your package only builds with newer gcc (e.g. >gcc-4.7).
+16. 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
 
-21. When should USE flags be used? What are the cases where they should be
+17. When should USE flags be used? What are the cases where they should be
     avoided? Consider the following examples. Explain what is wrong in them
     and how would you improve them.
 
 docs: devmanual, common sense
 
-21.a. A large C++ application with long build time has:
+17.a. A large C++ application with long build time has:
 
   # libcxx can be optionally used at run time via -stdlib=libc++
   IUSE="libcxx"
   DEPEND=""
   RDEPEND="libcxx? ( dev-libs/libcxx )"
 
-21.b. A large package with long build time has:
+17.b. A large package with long build time has:
 
   inherit bash-completion-r1
   IUSE="bash-completion"
@@ -200,7 +200,7 @@ docs: devmanual, common sense
     use bash-completion && dobashcomp contrib/bash-completion/foo
   }
 
-21.c. A package unconditionally installs 'foobar' executable which links
+17.c. A package unconditionally installs 'foobar' executable which links
       to libbar. The ebuild maintainer wanted to make it optional.
       He used the following code:
 
@@ -215,7 +215,7 @@ docs: devmanual, common sense
     fi
   }
 
-21.d. A package has numerous configure switches which control a number
+17.d. A package has numerous configure switches which control a number
       of optional features. All of them are enabled by default. They do
       not have any external dependencies, and do not affect the package
       size significantly. The ebuild author has added over 20 local USE