How to Be a Core Developer

The core CUPS developers have typically been tinkering with CUPS for many years (Mike since 1997!) and have had experiencing making changes to and/or packaging CUPS. To be a Core Developer we expect that:

• you have been working with CUPS for at least a few years,
• you are responsible for packaging or maintaining CUPS in some way, and
• you have an interest in fixing bugs and/or developing new features.

You should also be fluent in C and have a working knowledge of autoconf, make, and (for the corresponding platforms) Visual Studio and Xcode. And please read Developing CUPS for current coding style and makefile conventions.

General Development Rules

The master branch contains the current bleeding-edge code that is destined for the next Feature Release. Only approved pull requests or simple bug fixes and features (where the changes are small or isolated) should be pushed directly to master.

The vMAJOR.MINOR branches contain the current code for the corresponding prior Feature Release. Generally bug fixes from master will be back-ported and pushed to the previous Feature Release branch by the Release Manager for that release.

Monitor the CUPS Github Actions for changes that break the build. If you break it, fix it.

Developing Features

Features (unless they are trivial) must be developed on a side branch or fork of the master branch. Ideally you should create an issue for the feature to facilitate discussion, and then you create a PR from the branch/fork to facilitate a review of the changes.