Reporting a problem

Please, read the bug reporting instructions carefuly and send your problem report with the following link:

Bug Tracking Search

View last reported bugs

Search for an specific bug using its numeric Id.

If you know the number of the bug you are looking for, enter it below and click the Query button.

How to report a Problem

Stable versions bug reports

Before reporting bugs with stable versions, go through this checklist:

1. First check for patches and notes regarding the release.
2. Next find out if there is a newer release available.
3. The last thing to check is for changes made between hipergate versions.

If nothing looks like it addresses your bug, then please become acquainted with our bugtracker before submitting a bug report. An user account is required in order to submit a bug report. Once you are registered, you can use this form to report your bug.

Development version bug reports

If your bug is with the current source tree rather than a stable tree,

1. Test the bug at least twice, with source updated a few days apart.
2. Do not report source tree compilation problems, unless they persist. They are almost always your mistake or they are being worked on as you encounter them. People working on the project are building everything at least once per day, and usually several times per day with different environments.
3. Check for changes made between hipergate versions to see if the bug has been addressed.
4. Much care is made in creating snapshots. Sometimes mistakes are made, and our apologies are extended. Reading/writing the e-mail lists is more appropriate than sending in a bug report.

How to create a bug report

Always provide as much information as possible. Try to pin-point the exact problem. Never give vague instructions, or detail vague bugs like "it crashes" or "I get some errors on the debug log." Confirm that this issue is new, repeatable, etc. and make sure it is not a local bug.

Please don't start fixing bugs that require significant work until you are sure you understand them, especially during our release periods when we must not change major sections of code. If you are going to write significant amounts of code, check various forums to make sure that someone else is not working on the bug (saving duplication of effort).

The following items should be contained in every bug report:

1. The exact sequence of steps from startup necessary to reproduce the bug. This should be self-contained; it is not enough to send in a bare line with class invocation and other data you supplied to it. If a bug requires a particular sequence of events, please list those. You are encouraged to minimize the size of your example, but this is not absolutely necessary. If the bug is reproducible, we'll find it either way.
3. The output you got. Please do not say that it "didn't work" or "failed". If there is an error message, show it, even if you don't understand it. If hipergate fails with a particular error, say which. If nothing at all happens, say so. Even if the result of your test case is a program crash or otherwise obvious it might not happen in our testing. The easiest thing is to copy the output from the javatrc.txt file, if possible. Output from your servlet container will be also useful.
4. If you run third-party software which has to do with your bug, say so, including any subversion that software may have. If you are talking about a CVS or FTP snapshot, mention that, including its date and time.

Do not be afraid if your bug report becomes rather lengthy. That is a fact of life. It's better to report everything the first time than us having to squeeze the facts out of you. On the other hand, if your input files are huge, it is fair to ask first whether somebody is interested in looking into it.

Finally, when writing a bug report, please choose non-confusing terminology.

Sending in bug reports

Use the bugtracker system to get the bug into our tracking system. You can follow the tracking system at this web page.

Perhaps what you are sending in is a feature request, not necessarily a bug. New features are accepted, especially with code that implements your suggested new feature. If someone else writes code for your new feature, the chances are that it will be misunderstood and created so that you will not recognize it.

For debugging some bugs, we must have the software you are working with (Java version, servlet container, etc). Please remember that the hipergate project's resources are limited. We try to have a running testbed of all possible environments, help will be apreciated.

Types of bug reports in order of desirability:

1. Repeatable bugs with source fixes are the best.
2. Repeatable bugs.
3. Non-repeatable bugs -- or bugs you do not wish to repeat.