TariqShureih (Intel)

Project maintainer, OpenIPMI plugin, Sysfs plugin, Watchdog plugin

SuntrupthYadav (IBM)

Conformance Testing and Simulator Plugin

PeterPhan (IBM)

Blade Center plugin, Utilities, Clients, Testing

SteveSherman (IBM)

Blade Center plugin, Utilities, Clients, Documentation

BryanSutula (HP(E), Red Hat)

Project maintainer, Debian Maintainer for OpenHPI, HP BladeSystem c-Class plugin

ShuahKhan (HP)

HP ProLiant Rack Mount Servers plugin (iLO2 RIBCL), IPMI Direct plugin

RicWhite (HP)

HP ProLiant Rack Mount Servers plugin (iLO2 RIBCL), IPMI Direct plugin

JeanMichelAudet (Kontron)

IPMI Direct plugin

DanHorak (Red Hat)

Red Hat and Fedora Maintainer for OpenHPI, Python bindings, hpiview

RaghavendraPG (HP)

HP BladeSystem c-Class plugin

AntonPak (Pigeon Point)

Utilities, Clients, Client Library, OpenHPI daemon core

MichaelBishop (HP)

HP BladeSystem c-Class plugin (oa_soap), HP ProLiant Rack Mount Server plugin (ilo2_ribcl)

We also have some process guidelines for project members.

Contributor Guide

As OpenHPI is an open source project, it is important that a set of style guidelines and standards exist. Without this, the project very quickly will turn into a pile of mud that is undecypherable by anyone. This page lists the contributor guidelines for the OpenHPI project. Adherence to these guidelines will ensure a much more robust OpenHPI project.

Coding Style

From day one OpenHPI has adopted the Linux Kernel Coding Style guidelines as the base for it's style. For the convenience of our developers and users, this document is reproduced on our website. One should read it thoroughly before continuing. All patches must comply to those guidelines.

There are certain other items not specified in those guidelines that the OpenHPI team has standardized on. The first is return values from functions. In the grand C tradition, return of 0 indicates sucess, return of < 0 indicates failure.

The second is function level documentation. OpenHPI has adopted the gtk/gnome-doc format for function headers. This should be included before any function in the code. An example follows:

 * function_name
 * @firstparameter: This is the first parameter
 * @secondparameter: This is the second parameter
 * This is the description of the function. Note the blank lines that separate it
 * from the parameter list above and the return value explanation below.
 * Return value: 0 on success, otherwise any negative value on failure.
int function_name(sometype firstparameter, anothertype secondparameter)

Developers (last edited 2019-08-15 16:04:55 by sutula)

Related Sites:  SA Forum, OpenIPMI, Net-SNMP,