How GIMP Uses GitLab for Issues and Code Reviews

This article examines how the GNU Image Manipulation Program (GIMP) development team utilizes GNOME's GitLab instance to coordinate its open-source development workflow. It covers the life cycle of bug reporting and feature tracking through GitLab Issues, as well as the technical review, continuous integration, and merging procedures used to maintain code quality across supported platforms.

Transition to GNOME GitLab

The GIMP project operates under the GNOME umbrella and migrated from legacy systems like Bugzilla to GNOME's self-hosted GitLab instance (gitlab.gnome.org). This unified the project's source code repositories, issue tracking, and continuous integration into a single web-based interface, simplifying collaboration for both core maintainers and external contributors.

Issue Tracking and Triage

The GIMP team uses GitLab Issues as the central repository for bug reports, feature proposals, and task planning. The process relies on structured triage mechanisms:

  • Issue Templates: When contributors or users report a problem, predefined templates prompt them for critical system details, including the operating system, GIMP version, package source (e.g., Flatpak, installer), and reproduction steps.
  • Scoping and Labels: Maintainers apply standardized labels to categorize issues by subsystem (such as GEGL, Script-Fu, UI, or plug-ins), operating system, and severity. Labels also identify beginner-friendly tasks (e.g., "Newcomers") to onboard new developers.
  • Milestones: Issues are assigned to specific milestones, such as release blockers for major updates like GIMP 3.0. This allows the team to prioritize critical regressions over non-essential enhancements before tagging a release.

Merge Request Workflow

Code contributions enter GIMP through GitLab Merge Requests (MRs). The development team enforces a structured path from patch submission to integration:

  • Automated CI/CD Pipelines: Every merge request automatically triggers GitLab CI pipelines. These pipelines build the software and run automated test suites across multiple environments, verifying compatibility for Linux, Windows, and macOS. If a build fails or tests break, the MR cannot proceed without fixes.
  • Branch Linking: Contributors use commit messages and MR descriptions with standard keywords (such as Closes #1234) to automatically link merge requests to their corresponding tracked issues, ensuring documentation remains synchronized.

Code Review and Merging

The review process in GitLab ensures that all incoming code adheres to the project's architectural standards and licensing requirements:

  • Inline Discussions: Maintainers review the proposed diffs directly in the GitLab web interface, leaving inline comments on specific lines of code regarding style, memory management, and API design. Discussions must be resolved before the code is accepted.
  • Maintainer Approvals: While any community member can review code, only designated maintainers with write access have the authority to approve and merge changes into the main branches.
  • History Management: The team typically enforces clean commit histories, requiring contributors to rebase against the latest target branch and squash intermediate or fixup commits before the final merge.