openSUSE:Package maintainership guide
tagline: From openSUSE
- Build Service cross distribution howto
- Build Service Tips and Tricks
- Build Service Tutorial
- Creating a changes file (RPM)
- Java jpackage-utils
- Java RPM Macros
- Package dependencies
- Package description guidelines
- Package group guidelines
- Package maintainership guide
- Package naming guidelines
- Package security guidelines
- Package source verification
- Packaging checks
- Packaging Conventions RPM Macros
- Packaging desktop menu categories
- Packaging Fonts
- Packaging Games
- Packaging Go
- Packaging guidelines change process
- Packaging Haskell
- Packaging init scripts
- Packaging Java
- Packaging Lua
- Packaging Multiple Version guidelines
- Packaging Patches guidelines
- Packaging Perl
- Packaging PHP
- Packaging Ruby
- Packaging scriptlet snippets
- Packaging wxWidgets
- Packaging XML Schemas and Stylesheets
- Ruby Gem Strategies
- Shared library packaging policy
- Specfile guidelines
- Systemd packaging guidelines
- Packaging guidelines
The development of openSUSE Tumbleweed and the subsequent release of the distribution is supported by the technical roles outlined below. The roles defined provide a general guideline and set basic expectations. Each person filling any one or multiple roles has the freedom to interpret these guidelines to fit her or his desired participation level.
- You should submit and manage your package in openSUSE Tumbleweed and follow the How to contribute to Factory guide.
- Your package should always build in the devel project as described in the above guide for openSUSE Factory/Tumbleweed project.
- You decide and enable/disable all the projects you want the package to build on (SLE, openSUSE,...).
- You are to review in a timely manner all the submissions sent against your package. This should be around a week so you should be able to work on openSUSE only as your week time permits.
- You should respond on bugs and email questions about the package in the same time frame.
- You should adhere to the general packaging guidelines as outlined in this wiki section overall
- You inheritingly are the guy everyone reports issues to, the only difference compared to the maintainer is that you don't have direct write access to the project/package you are set as bugowner to.
Devel project maintainer
- Instead of maintaining just one package you are set as maintainer of all the packages in the specified devel project
- You have all the responsibilities of the package maintainer for all the packages in the project
- If there is set package maintainer for package in the project you should give him the time to react himself as per rules for packager. There are exceptions from this rule for:
- whitespace/typo fix
- urgent build fix (package broke build of most other packages in the project or in openSUSE Tumbleweed)
- You should encourage occasional contributors to become package maintainers if they submit often and show skills required for the task