1.	Q: Which version of Ant (or JUnit or log4j or...) does Gump use? A: The latest from cvs.
2.	Q: Gump is building the latest version of everything? That could never work, could it? How can you debug anything when you have so many variables to deal with? A: It isn't as hard as it seems. Getting it to work initially was done by incrementally adding one project at a time. Keeping it working is only requires a small amount of effort over a long period of time. When builds are "mostly" clean and frequent, isolating problems is fairly easy. Rollback projects one by one until the problem disappears, and then reapply changes within that project one by one until the problem reappears. I've used this technique numerous times to produce test cases and patches to projects that I know virtually nothing about their internal design.
3.	Q: I've just got a "nag" e-mail about a failure...what should I do about it? A: This question deserves it's own web page.
4.	Q: I've got a fix, how do I get Gump to pick it up? A: Check it into cvs.
5.	Q: I checked in a fix, how do I know if Gump picked it up? A: On the build log, click on the link marked cvs. It will tell you when the latest cvs update or checkout was performed and what source files were obtained in the process.
6.	Q: How do I get nagging to stop (or start)? A: If there is consensus on your project, send an e-mail to alexandria-dev@jakarta.apache.org letting us know what the outcome was, and it will be respected.
7.	Q: My project depends on a specific version of a dependency, how can I get Gump to use that version? A: The combinatorics of building each project with distinct versions of its dependencies is a bit too much for me to track. If the dependent project is undergoing a major revision, and the prior version is still actively supported, exceptions may be made. Otherwise, feel free to set up your own builds, with or without using the codebase of Gump to track the set of dependencies that interest you.
8.	Q: I've got a change I would like to make to the project definition for a project I'm a committer on...how do I get the change to be made? A: Submit a patch to alexandria-dev@jakarta.apache.org. If this is likely to become a regular occurrence, and you demonstrate some ability to work with (or even run) the existing code base, then we'll likely vote you in as a committer.
9.	Q: How do I get a project to be added to Gump? Must it be an Apache project? A: Send an e-mail (preferably a patch) to alexandria-dev@jakarta.apache.org. Being Apache related (i.e, used by or a consumer of other Apache projects) helps, but is not required. What is important is that your code be publicly accessible via cvs and that it be buildable in an OS independent manner.
10.	Q: Shouldn't the project definitions for a project be kept within the project itself? A: That was part of the original design (in fact, you will notice that all modules are referenced via "href" attributes.) When the project was completely XSLT based, it probably worked, but now that part is in Java, so it will require a small amount of code. All that code is in one place, so it should be relatively straightforward to address this need. There still will need to be a small amount of "locator" information in Gump, but the contents of the project definition could be elsewhere.
11.	Q: Why is Gump merely a "proposal" and not a Jakarta subproject? A: While it has a large user base (developers who find this information helpful and base decisions on the results), Gump itself does not enjoy a large development community. Once more people actually run the tool themselves and a few submit an occasional patch, it will be. And there still is a faint hope that the embers still smoldering in the Alexandria community will reignite, and a merging of the two code bases will make sense.