Revision as of 10:45, 24 December 2008

 

Home

 

Download

 

News

 

Support

 

Admin

 

Dev

 

Screen Shots

 

Grid List

 

Bugs

Languages:

English    Deutsch    Français    日本語

Support and Contribution Process

Before asking for help

• Search the User Documentation before asking for help.
• Search the FAQ
• Check your configuration files for any obvious defects.
• Check that you're starting up the processes correctly.

Getting support

• Ask on irc.freenode.net #opensim and #opensim-dev. Approach them in that order :) Please be courteous and remember that the developers and anyone else assisting you are volunteers there.
  • Don't ask to ask, just ask.
  • Phrase your question in the form of a question.
  • Be specific.
  • Explain the problem.
  • Describe how to reproduce the problem.
  • If you need to paste configuration files or error messages, please paste to pastebin then send the link in the IRC channel.

• If no-one in IRC is able to help at the moment, you can try one of the three mailing lists that are available for communication between users and developers.
  • opensim-users - a user support forum for OpenSim
  • opensim-dev - development discussion of OpenSim
  • opensim-commits - an email list for svn commits

After you get help

• If the problem is a bug, and no-one is able to help you, please submit a bug report. Read below for how to do this.
• If someone did help you, please document the problem and the solution on the wiki if it's not there yet

Attending office hours

If you would like to contribute to the project, the second thing you may want to do(after learning about the project) is visiting the in-world OpenSim discussion hours.

Bug Reports: Mantis

The mantis tool is one of the main channels of communication between opensim users and opensim developers for purposes of reporting bugs. It is NOT a costumer support tool, because there is no costumer support within the opensim project beyond that provided by volunteers in the opensim IRC and mailing list.

This explains how to file a mantis that really helps the development of opensim.

If your main interest is to have your problem solved, rather than help the development of opensim, mantis is the wrong tool for you. Try signing on to #opensim IRC for that kind of help, where you can talk to other opensim users, exchange experiences and get personalized volunteer help.

If you're willing to invest time to investigate the problem you are experiencing, your effort will be very much appreciated. You should look at mantis as half-way between your effort to solve the problem and the developers effort to do the same. For everything else, there's the several IRC channels, mailing lists, and assorted grid-specific forums.

When you encounter a problem, before filling a mantis, ask yourself the following questions:

• Are you the only one experiencing this problem or are there other people experiencing it? The fastest way to find an answer to this question is to sign on to the #opensim IRC channel and exchange a few words with other opensim users there. Another way is to browse/search this mantis tool. If you're not the only one, then chances are it's a real issue. If you're the only one, chances are you're doing something wrong. The mantis is the wrong place to report it, you're better signing on to #opensim. In any case,
  • Is there something broken in your setup?
  • Look at the OpenSim.log file. Is there something informative in there that will help you understand what's going on with your setup? An exception perhaps?

• Can you reproduce the problem systematically? Take time to understand the steps that lead to the problem. The more reproducible and understood the problem is, the higher the chances it will be fixed. If you can't reproduce it, there is very little chance that the issue will be fixed. But reproducibility to you is not enough. Read on.

• Can you describe the problem to developers so they can reproduce it without being you?
  • The best way to do this is to try to reproduce the problem in a standalone setup. This eliminates all the extra noise that adds fuzzyness to the issue. So try it in standalone first. If you are able to reproduce it like that, the chances of the problem being fixed soon increase dramatically. If the problem is related to the Hypergrid and distributed setups, try to reproduce the problem in only one machine with 2 opensim instances. From a developer's perspective, it will be easy to take your good description, reproduce it on their own standalones, and then fix it.
  • If you can't reproduce it in standalone mode, try to reproduce it in grid mode using the simplest possible grid -- something that a developer can also set up in one machine without much work.
  • If you can't reproduce it that way, and the problem only occurs within your special grid environment, chances are there's something wrong with your special setup. Furthermore, the chances of a developer being able to fix the problem soon decrease dramatically. You may try to hire someone for a fee in order for him/her to take their time to investigate the issue on your grid.

Bug Description

Once you understand how to reproduce the problem, describe it on mantis, along with a step-by-step recipe for a developer to reproduce it. In an ideal bug report, the description should be something like this:

Setup (standalone/grid/...), as detailed as possible

1) Do A

2) Do B

3) Do C

...

==> bang! problem

In every step, be as specific as possible, leaving no room for interpretation. For example, saying

"x) crash the client by pulling up the task bar and killing the SecondLife process" is MUCH better than

"x) crash the client";

and

"y) create a new region by using a command like this on the console: create region ..." is MUCH better than

"y) create a region".

Remember, the purpose of your description is to help a developer experience the steps that lead to the problem, so that he/she can then fix it.

When not to file a bug report

Simply reporting a problem that you are experiencing is ok but it's completely ineffective for purposes of problem fixing. Mantis should not be used for that. Instead, report generic and/or non-reproducible and/or special setup problems informally in #opensim and/or #opensim-dev. Here are two examples:

- "TPs seem to be broken in OSGrid with r1234": report that in osgrid-related forums and #opensim

- "TPs seem to be broken altogether with r1234, and lots of ppl are seeing this too": let the developers know about it in #opensim-dev, maybe. They probably already know.

If all you can say about an issue is it's brief description, just like the examples above, mantis is the wrong tool for it. Don't file a bug report, it will be closed promptly.

Feature Requests

You may have an idea for moving opensim into an interesting direction that hasn't been explored yet. If you do, the process is as follows:

• Describe your idea either in an email message or, better yet, somewhere on the Web. Then start a discussion about it on the opensim-dev mailing list, to have a feeling for what the developers think about your idea, and to get some advice on how to go about implementing it. If the feeling you get is that the developers are not interested, you can always implement your idea as a GForge project or as your own proprietary extension. If you get the feeling that there is a chance your idea will be accepted as a core contribution, read on.

• Implement your idea on your own copy of opensim, and make it available for users and developers to try it out without much effort. The lower the effort for people to try it out, the higher the chances people will try it and accept it.

• If you're not a programmer, your only possible course of action is to convince some programmer (core or not) to implement it for you. Keep in mind that the opensim developers do not work for you, and are busy implementing the things that interest them. And if an idea is just an idea without code behind it, it will be ignored.

• Once you have an implementation, submit it to the developers via a core patch on mantis. All patches submitted via mantis are evaluated by the core developers, possibly discussed with the submitter for further clarifications and improvements, and applied to the core code if there are no objections.

Patch Review

The developers also use Mantis to review patches for inclusion in opensimulator's core SVN.

• There are several guidelines to the patch review process. You will need to agree to our contributor agreement and be willing to take feedback on the patch. Not all patches will make it into OpenSimulator for a variety of potential reasons. OpenSimulator is not trying to be 'everything for everyone' so, often, it's requested that the functionality be implemented in a module that gets it's own project on forge.

• After you have submitted a patch, please ensure to update the title of the bug with [PATCH] - Fixes /Issue/.

• General turnaround time for patch review is 48 hours.. though, it could be up to two weeks depending on the situation. Generally, if nobody comments on your patch within 3-5 days, pop into #opensim on IRC and make sure that you remind them of the PATCH.

UNIQ3a70b191481ae1a-cleanpage-00000000-QINU