OpenCV project still lacks some documentation about the development process. As a result, there is a lot of confusion among co-developer. OpenCV development team is working on this, and today we want to point to a new wiki page, that exposes some important information. Many thanks to Daniil Osokin who worked on it!

On that page you can find info about the "2.4" and "master" development branches, and a diagram, showing pull request lifecycle. We hope that this would help to those of you, who is going to prepare a pull request with some cool new code!

Those who contribute their changes in the form of pull requests can now see the results of automatic testing. http://pullrequest.opencv.org page shows the results of tests on 3 major operation systems, and more to come. This allows you to debug/improve proposed changes, and easily test them even on foreign platforms. When your pull request is "green", somebody from the core OpenCV team will review your contribution, and possibly merge your work into the central repo!

Please choose carefully the branch that you work with and that you make the pull request to. The simple rule of thumb is that if you're doing a fix, please prefer 2.4 branch. In this case your fix will go to the 2.4 maintenance branch and then will be automatically merged to the master. All such fixes will be included to the 2.4.4 release, which is going to be very conservative. All the new functionality should go to the master branch, so it will be considered for the next major 2.5 release.

As you all know, OpenCV team has migrated to Git DVCS, and we have mirror on GitHub (https://github.com/Itseez/opencv). Many contributors has already started to provide patches in a form of pull requests. This model is very convenient and allows to easily review, test and integrate your change sets. What is also important, it allows to preserve your name in the repo history ;-) So, if you really want to see your stuff added to the master, please consider sending pull requests.

Currently we have 66 patches at the tracker. OpenCV development team will consider all of them during the next hackathon, and they will be probably added to the code base before the 2.4.3 release. But please choose the github next time you want to improve something in OpenCV. It is also possible that we'll rename the Patch tracker here to the Bugfix. That will mean that we accept bugfixes in any form, but patches with a new functionality should go to the github, where they will be reviewed.

Every time you submit a patch, please mention a Git commit which was used to generate a patch. Use

commit:<first 6 digits of SHA ID>.

For commit to become a hyperlink, which is often useful. SHA ID's of the last commits can be obtained by running "git log" command in the working copy.

And please use the proper formatting style for everything. Every text field has the following link in the top right corner: Text formatting. It shows the markup, which helps to make you messages readable.

Dear all!

Every time you provide a code sample or a console output (build log, CMake report), please format it as a code. You can use the pre tag for this:

<pre>
 several lines
 of code
</pre>

It greatly helps to parse the listing visually. For more information you can check these short or long help pages. Redmine has a nice wiki syntax, so please use it extensively. BTW, if you found a non-formatted code sample, please fix the formatting, it will definitely improve your karma :)

Please provide the output of this function every time you report a bug about the trunk version of OpenCV. May be the problem is in your build settings, so the log can greatly help us. Unfortunately cv::getBuildInformation() is not documented, but you can find some information here: #645.

Hello,

If you found a duplicate ticket, you shouldn't add a comment about it, use the Related issues field instead. You can find the field at the very bottom of the issue description box. So, the correct procedure is the following:

1. Click the Add hyperlink near the Related issues field.
2. Choose the proper relation between issues ("duplicates" in this case).
3. Close the duplicate with the Cancelled status.

So, please follow The Boy Scout Rule: "Leave the campground cleaner than you found it". Each time you can help to the OpenCV, please do it ;-)

Regards,
OpenCV Dev Team

Dear all!

We've opened this News section at Redmine to communicate with those of you who has enough courage to deal with the trunk version of OpenCV ;-) Here we are going to inform you about the latest trends in OpenCV development. We will publish some hot news right from the battlefield, inform you about upcoming changes in the library design and development process, we're also going to ask for your help when needed. So, this tab will be especially useful if you're ready to participate in the development process and to help us make the library better!

This is the first time when we want to ask for your help. Please follow the rules below while working with tickets. These rules will help us to better coordinate the work and to reduce the amount of noise on the tracker.

1. Please comment existing tickets with "+1", this is recommended way to draw our attention to the issue. Don't create annoying duplicates.
2. Use the "Normal" issue priority by default. Don't spam with the "Immediate" priority unless you're a core developer and ready to start the work immediately.
3. Don't use the "Target version" field for new tickets unless you're responsible for iteration planning.
4. But please set the "Target version" if you're closing the ticket. This would help us to track the iteration progress.

Regards,
OpenCV Dev Team