The following guidelines for community contributions to the RHQ project are aimed at making the process of integrating development from multiple different parties as smooth as possible. Following the guidelines will greatly increase the chances of any given change being incorporated into the main RHQ development branch.
Finally all contributors must agree to the Fedora Contributor License Agreement before any contribution can be accepted. See here for more information.
Bugzilla project: https://bugzilla.redhat.com/page.cgi?id=browse.html&product=RHQ+Project
Git repository: http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=summary
Development mail list: https://fedorahosted.org/mailman/listinfo/rhq-devel
IRC channel: irc://irc.freenode.net/#rhq
Wiki: http://www.rhq-project.org/display/RHQ/Home
The guidelines below assume the change is relatively small, simple and self contained, if it's a big/complex change then it should be treated following the Feature Development guidelines below. Completely trivial fixes can normally be committed directly and only a need a supporting Bugzilla entry.
Check if an issue exists in Bugzilla for the bug. If one does not exist, create a bug describing the problem, and if possible reproduction steps. Include any stack trace, and if appropriate screenshots of the observed behavior.
Go code! Making sure to follow the Coding Standards
Where possible additional tests should be added to confirm the fix, similarly tests cases could also be added to the bugzilla entry.
Under no circumstance should the change introduce regressions into the testsuite.
Sync with the appropriate RHQ branch and create a patch containing just the fix, using git format-patch, and attach it to the original bugzilla issue.
Post to the development list that the patch is ready for review. Someone will review the patch and, if necessary, request updates to it.
Once a fix has been given a +1 on the development list, committers should merge the change into the RHQ master branch, and mark the bug as resolved.
The commit message should start with a reference to the bugzilla issue
Non-committers will have the patch applied on their behalf.
These guidelines are for larger chunks of development, i.e. most features and large bug fixes. Small fixes can usually follow the more streamlined approach above.
Check if a tracking issue exists in Bugzilla for the feature. If one does not exist, create a bug describing the intention of the feature, what if any existing features it replaces or depends on. Make note of any issues known at the time, e.g. potential complexity, backward compatibility issues.
Discuss the feature on the development mail list, e.g. bugzilla url, general implementation strategy or outstanding design questions. Document design decisions on this list. Conversations on the RHQ irc channel are encouraged, but the conclusions need to be posted on the main development list.
The RHQ wiki is a great place for committers to write up design ideas prior to discussion.
For features which replace existing implementations, it should be discussed if the use of a "plugin model" is needed (to let alternative implementations be swapped in and out).
Go code!
Iterate on steps 2 and 3
If you are a committer to the RHQ project and you want to use the RHQ git repo for developing this feature, create a topic branch for the work.
Topic branches must be specific to the feature being implemented and should not include other features or bug fixes.
Non-committers should clone the RHQ git repo and develop in that repo.
Features intended for merging into the RHQ master branch need to be reviewed and accepted via the development list.
First off notify the development list that the feature is ready for review and include a link to the branch or external public repo where the work is available.
If the change is small/simple the results of git format-patch could just be attached to the original bugzilla entry.
Where possible additional tests should be added to the testsuite to cover the new feature, similarly tests cases could also be added to the bugzilla entry.
Under no circumstance should the change introduce regressions into the testsuite.
Incorporate any feedback resulting from the discussions.
Iterate on steps 6 and 7, until agreement is reached on the development mail list that the feature is ready for merge into the master branch.
The type of feature being developed will play a big role in this process, for simple features this could just be a quick sanity check for larger features this could involve a more thorough review of the scope and impact of the feature.
Assuming agreement to merge is reached, and a +1 received on the list, committers should merge the change into the RHQ master branch, and mark the bug as resolved.
The commit message should start with a reference to the bugzilla issue
Non-committers will have the patch applied on their behalf.
We're investigating the use of additional tooling, such as gerrit to help stream line the review process and make sure submissions don't get buried. If anyone has any experience with this or other similar tools please post opinions on the development list.