Project Maintainers

From OR1K

The project maintainer is the "champion" for a particular component of the OpenRISC project. A key role is to act as a guardian of quality in their component. In particular, nothing should be committed to a repository until it has been reviewed and approved by the relevant maintainer.


List of maintainers

Current maintainers

Please fill in anything that's missing. Julius, Jeremy

Vacant maintainer roles

A number of these components have temporary maintainers, to allow orderly handling of changes in the repositories. However permanent maintainers, who are able to commit to driving the development of the component are urgently needed.

Proposed maintainer roles

As the OpenRISC project grows and matures there is a need for maintainers to appointed to to manage various components of the project.

At present there are some well-defined maintainer roles being fulfilled by contributors for the upkeep of, for example, or1ksim(Jeremy Bennett) and the Linux kernel port (Jonas Bonn).

There is a need to define roles for maintainership of other parts of the project and assign them to people.

Roles that could be defined and assigned immediately are:

  • OR1200 specification and RTL maintainer
  • OR1K architecture specification (document?) maintainer
  • Nightly build maintainer
  • add another role here!

Responsibilities of a maintainer

I've only just added this - not sure how much of this is appropriate or necessary! Julius
More ideas added by Jeremy

The main responsibilities of a maintainer would be:

  • Be active in, and responsive to, the community's work with their component of the project.
    • maintain the Wiki pages relevant to their component
    • answer mailing list and forum questions relevant to their component
  • Outline a preferred method of development and release for that component
    • decide how patches will be submitted, reviewed and applied (consistent with the overall project approach)
    • outline an approximate release/development cycle (consistent with the overall project cycle)
  • Review and approve any changes to their component before committing to trunk
    • as the project grows, the maintainer for a component may recruit additional reviewers to add him/her.
  • Have the ultimate say in any contentious development issues
  • Help the project progress and develop

© copyright 1999-2017, equivalent to ORSoC AB, all rights reserved. OpenCores®, registered trademark.