How to Make Good Bug Reports for Pellet
Making good bug reports is a valuable part of any software development process, particularly open source software like Pellet.
Where to file a bug report
If you have a tech support contract, use the communication channel we established at the outset of the contract. For everyone else, we only support Pellet on the pellet-users mailing list; please do not email the developers directly. See the pellet-users site for information about subscribing to pellet-users.
Things to do before filing a bug report
1. Read (or re-read) Tips for getting good customer support.
Please don’t assume your bug report will be answered in a timely fashion or at all. Pellet free support is on a best-effort basis. That’s a nice way of saying we may not be able to respond. If your support needs are urgent, a support contract is the only certain means of getting a rapid response from us. See our support contract page for more information.
2. Try to reproduce the bug or ask someone else to reproduce it, ideally on the most recent release of Pellet and from one of Pellet’s command line utilities. (Unless you have a support contract with us, we don’t normally support anything but the most recently released version of Pellet.) You might also try reproducing the bug with another reasoner, like FaCT++.
3. Consult BUGS.txt in the Pellet distribution and Trac open tickets to determine if this is a known issue.
4. Try to isolate the bug, both in code and data. If you can reproduce the bug with either (1) a subset of the data or (2) yr code, that will make the bug report much more valuable. The ideal is to be able to isolate the minimal data & code necessary for someone else to reproduce the bug; though, like all ideals, approximations are helpful, too.
5. If you are reporting a performance-related bug, consider running Pellet lint from the command line. If it makes recommendations, you might try implementing them in yr data to see if that addresses or improves the problem. Run pellet help lint for more information.
Remember: reporting bugs about versions of Pellet more than two older than the current release is probably not going to result in a response, unless you have a tech support contract.
And, note, that pellet-users is not the best forum to ask basic questions about OWL, DL, logic, Java, Protege, Semantic Web, RDF, ontologies, or modeling. There are better forums for all those questions. Be relevant.
Bug Report Format
Please send only one problem per bug report email; if you have two related problems, include them both. But for more than one unrelated problem, please file one bug report each.
A good bug report is an email message sent to pellet-users mailing list and probably includes most, if not all, of the following information:
- A concise summary of the problem
- Specific version identifiers for Pellet (
pellet -v), JVM, JDK, Jena, OWLAPI, etc. - Which Pellet subsystem were you using? One of the command-line tools? Some module via custom code?
- A description of the process required to reproduce the bug, if you or someone else is able to reproduce it. Remember that Pellet’s automated reasoning process can be non-deterministic, so it may take several runs to reproduce a problem.
- JVM stack trace should be edited to the most relevant section, if possible. If you are not able to isolate the relevant portion of the stack trace, it should be attached to the bug report. Please do not include stack traces in the body of your bug report.
- Any custom code and data necessary to reproduce the bug, as attachments or, even better, include URLs to the code or data in a pastebin or similar app. Note: if your data or code is sensitive, you might email an inquiry to see if we can look at the code or data privately.
- Please feel free to include specific sections of code or data in the bug description if are reasonably certain they are relevant; i.e., you are an experienced user.
