This is part of the community eLxr documentation and handbook in the making to describe the eLxr Maintainer rules. The final destination of this document is still to be determined, for now I will start here on the forum.
The below description is a base setup and is always open for feedback from anybody. The description is subject to change.
Being an eLxr GitLab project Maintainer means you adhere to the following responsibilities:
- Responsible for maintaining the Debian package building, if applicable for the project
- Making sure the package remains on-par with the upstream Debian version of the package in case the package is derived from a Debian package
- Making sure the package remains on-par with the upstream source code version, in case the package is eLxr specific and not derived from Debian
- Responsible for maintaining proper versioning
- Responsible for package publishing into the eLxr repositories
- Responding appropriately and adequately to reported bugs and security reports
- Responsible for maintaining the GitLab project and quality requirements
- All changes must be reviewed by at least 2 developers. Preferably at least by one maintainer to gatekeep the quality.
- All pipelines on the GitLab project must succeed without failure before they can be merged into a protected branch.
- Any exceptions to the above must be properly documented on the specific GitLab project.
Projects are allowed to have multiple maintainers. As such a team of maintainers is possible.
In case a project seems unmaintained, the eLxr Community Leader will reach out to the GitLab project maintainers. In case no prompt response is given in good time (30 days), the eLxr Community leader will take the liberty to remove project maintainership to prevent from unmaintained packages and projects. With that opening up the project for new maintainers.