This is the home page for most of the OpenPegasus project technical activities.

Project Management Committee

The OpenPegasus Project Management Committee (PMC) is responsible for the technical aspects of the project. PMC membership is by invitation issued by agreement of the existing PMC members.

The PMC also grants recogniton to those members of the community who demonstrate expertise and commitment to the project by granting then binding voting rights on technical changes. These 'Committers' form the group that approves and can veto technical changes. Individual Committers may be contacted using the links below.

The current Committers are:
 

Emritus Committers:

How Technical Changes Get Made

All changes to the project are reviewed and have to be approved. All changes also have to be documented in a Bugzilla bug report. This includes bug fixes, minor enhancements, and new functionality. New functionality may also need to be described in one or more Project Enhancement Proposals (PEPs) which are used to describe the proposed functionality and the details of the implementation.

All contributions to the project are covered by the OpenPegasus Contribution Agreement (see below).

Full details of the processes for doing making changes can be found in PEPs #336 and #337. A short summary of the process for getting a patch approved is as follows:

1. Create a Bugzilla report
2. Attach the patch to the bug report
3. Find a Committer to sponsor a vote on approval of the request
4. Await the outcome of the vote. Approval will be be indicated by the setting of the X.X.X_APPROVED keyword in the bug, where X.X.X is the release number, e.g. 2.8.1

There a few additional basic rules to be observed when proposing patches:

1. Wherever possible, patches should be tested on more than one platform, one of which should ideally be Linux or Windows.
2. The day after a patch is committed, check the Nightly Build and Status page to ensure that it hasn't broken the build on any platforms it hasn't been previously tested on. The golden rule here is 'patches should not break the build'.
3. All patches must be committed to the head pf the main branch before being back-ported to earlier releases. Back porting requires that the patch be applied to all branches between the head and the earliest release to be patched working back in reverse order, e.g. patch main, 2.8.1, 2.7.3, 2.6.3 in that order. Each branch patched requires a separate Bugzilla entry.

Contribution Agreement

All contributions to the project are covered by the OpenPegasus Contribution Agreement, which must be signed by all contributors to the project.

The PMC grants CVS commit rights to developers who have earned merit by demonstrating expertise and commitment to the project. Initially developers will submit patches which will probably be committed by the Committer who sponsors the patch approval vote. Proposing successful patches is a good way of earning merit.