What follows are some of the general process guidelines we use within the OpenHPI project. This information is primarily intended for OpenHPI project members.
(The following is work in progress...not finished yet.)
Mailing Lists
The OpenHPI project makes use of a number of mailing lists. Project members will probably want to be subscribed to the following active lists, in order to contribute effectively.
openhpi-announce Limited to announcements concerning the project. Low volume. OpenHPI users will probably subscribe to be informed of new versions.
openhpi-devel General project development and user support mailing list. Project discussions happen here.
openhpi-tracker Subscribe to be notified of new and changed bugs and feature requests. Note that some future direction discussion takes place here, in the form of feature requests.
openhpi-svn If you make changes to the OpenHPI source code, or otherwise want to be aware of what is being done between releases, subscribe to the openhpi-svn mailing list.
Source Code Repository
Example check-out command (confusing because there are two levels of "openhpi", e.g. svn co https://openhpi.svn.sourceforge.net/svnroot/openhpi/openhpi/trunk openhpi
- Structure (trunk, branches for releases, other pieces kept here e.g. snmp subagent)
- Commit best practices
Ideally, each commit is referenced to a SourceForge Tracker defect or feature request
- Try to do a single commit for each related change, so that individual svn revisions reflect a consistent state of the repository and can be built without error
- Though any project member can change code anywhere, please respect maintainer boundaries. (See Developers.)
SourceForge Tracker
- We use tracker not only to track project defects, but also to track and discuss planned enhancements and future directions.
- Suggest that active members be subscribed to the openhpi-tracker mailing list (because of the above)
- Using "Group" to indicate what version the fix/change applies to. Set to the next (upcoming) release when closing the defect.
- Please include the svn commit revision as part of the Comment field, when closing an issue.
- If this is a bug fix, should the fix be ported to the current stable branch as well as the trunk?
Release Procedures
There is separate documentation for the OpenHPI release procedures, since most members will not have to do this. It is here.
Wiki Administration
There is also separate documentation for the OpenHPI wiki administration. It is here.