Skip to content
Snippets Groups Projects

Gerrit and Bugzilla deprecation and migration plan

Last edited by Matt Ward

Summary

The Eclipse Foundation supports three development environments, and is proposing a plan to deprecate the usage of Gerrit + Bugzilla, migrate off that platform through June 2024, and ultimately remove both services by May 2025.

Background and Motivation

The Eclipse Foundation (EF) currently supports three development environments:

The current proposal is based on the following motivations:

  • To remain current in the technical landscape. Although Gerrit is under regular development, Bugzilla is not actively developed anymore; its last stable release was 5.0.6, on Feb 09, 2019.
  • To remain relevant. Most new projects coming to Eclipse have roots in GitHub or GitLab. Bugzilla has been largely irrelevant for over 10 years.
  • To keep up with developers’ desire for more modern and integrated tools.
  • To allow IT staff to focus on services that add value. Duplicate services add little value.

To that end the Foundation’s IT team will standardize its code hosting, issue tracking and Wiki solutions on GitLab (hosted by the Foundation) and GitHub as the project development tools of choice.

What’s been done so far

A dozen projects have already moved, or their migrations are in progress. The Bugzilla->Gitlab import process is functional. A Bugzilla -> GitHub Issues migration script is known to exist but has not been needed yet. A Proof of Concept has been built for the project website transition to a new domain, eclipseprojects.io.

What needs to be done

Project Migration Phase

Help Projects migrate from Gerrit/Bugzilla to GitLab or Github:

  • Provide Documentation, FAQ/How-Tos and examples of successful project migrations
  • Agree on a timeline with projects and their communities
  • Clone repos to GitHub/GitLab
  • Move project websites
  • Migrate Bugzilla bugs to GitHub/GitLab Issues
  • Mark existing repos and bugs as Moved/Read Only

Post-migration phase

  • Long Term Bugzilla Data retention
    • Create a static index of all 550,000+ bugs
      • Likely a series of paginated indexes
      • Actual implementation may vary
    • Archive all 550,000 bugs individually as one static html page per bug
    • Disable the Bugzilla Perl application
    • Create server redirects to ensure existing links to bugs function
  • Long Term Git Data retention
    • At this time, all Gerrit repositories should be marked as “Read Only” with links to the new location
    • Disable Gerrit Code Review system 6 months after the last project has migrated
    • Add links from https://git.eclipse.org/r to the cGit browser, https://git.eclipse.org/c and maintain cGit functionality, with clear indications that the repos shown are archived, for two years. This will allow developers to browse the code as it was snapshotted at the time of migration.

Proposed timeline

Throughout the entirety of this timeline, the IT team will use mailng lists, eclipsestatus.io, Twitter and other means of communicating with projects the upcoming activities ahead of time.

Jan-Mar 2022 COMPLETED

Send shutdown reminder to most active Gerrit projects encouraging them to move to GitLab/GitHub

Apr-Jun 2022 COMPLETED

Notify projects that:

  • project websites will be moved to eclipseprojects.io, (with redirects) and once the move is complete we will begin migrating project website repos to Gitlab in Q3
  • new Gerrit repos are no longer available, only Gitlab/Github repos will be created (some exceptions for legacy projects etc)

Jul-Sept 2022 90% COMPLETED

Move project website repos. This will require:

  • Changes to the checkout script
  • A modification to projects.eclipse.org to allow the specification of a ‘website repo’
  • NOTE: Only projects that are actually using their website repositories will be moved. If a project website repo contains only the default redirection to projects.eclipse.org that repo will be replaced with a server-side redirection to projects.eclipse.org. Currently it appears that ~50% of projects use projects.eclipse.org as their default website.

Oct-Dec 2022 COMPLETED

Announce compulsory migrations (GitLab as default) starting with the least active projects, and adding some redirects on Gerrit to point at the new locations. Work to commence in April 2023, and target June 2024 as the move end date.

  • One announcement made November 14, 2022
  • One announcement planned December 14, 2022. Projects are welcome to immediately plan a date in the future that is convenient for them, by filing a HelpDesk issue, but those projects that do NOT make their timing preference known will be required to move as webmasters will randomly select 15-20 migrations per quarter until June 2024.
  • BZ -> GL import working
  • BZ -> GH Issues import unknown; tool selected #679
  • Bugzilla product marked as read-only (Not open to new bugs), comment added that mentions the new location of this project's issues, then leave as-is

Jan-Mar 2023

Test Bugzilla to GH Issues tool, and re-test Bugzilla to GL Issues too.

  • #679

  • Bugzilla product marked as read-only (Not open to new bugs), comment added that mentions the new location of this project's issues, then leave as-is

  • Identify 15-20 projects to move in Q2 (April-June).

Notify their -dev mailing lists and create a tracking issue on GitLab HelpDesk. We will be flexible and accommodating with projects and the plans for migrations. If a project is non-responsive after 30 days of contacting them to establish a migration plan, we will work with the Foundation's project team to determine if the project is still active and terminate inactive projects, or migrate to GitLab by default.

April 2023 - June 2024

  • [Q2 moves due May 15, Q3 July] Perform migrations and select more projects to notify/move for the following quarter.
  • [Denis 2024-Q1] Provide a static Proof-Of-Concept Bugzilla instance. (pagination based on project, not bug numbers)
  • [Matt ML mid-May] Communicate overall progress as we go along.
  • [2023-08-22] Jakub to pick 2023-Q4 projects, and communicate with them by Sept 8.
  • Pick 2024-Q1 projects, and communicate with them.
  • [Matt ML mid-Nov] Communicate overall progress as we go along.
  • [Matt ML Jan/Feb] Communicate overall progress as we go along.

Oct 2024

  • Send service shutdown reminder notices for Gerrit/Bugzilla/Cgit targeting May 2025
  • Test service URL redirections
  • Schedule Gerrit brownouts January 29th 2025, March 5th 2025, April 23rd 2025

May 2025

  • Shutdown Gerrit code review, redirecting to Gitlab/Github as needed
  • cGit stays active, with Archived/Moved notices
  • Take the final snapshot of Bugzilla and deploy a static copy
  • Shutdown Bugzilla
  • Archive Bugzilla data and configs, with a 6 month recovery window.
  • Investigate possible redirects for cGit to current project repos
    • Check logs for cGit activity to see if it's even worth it

May 2025 - Dec 2025

Schedule brownouts for the cGit browser service Shut down cGit browser, redirect the service to Eclipse GitLab.

Copyright © Eclipse Foundation, Inc. All Rights Reserved.     Privacy Policy | Terms of Use | Copyright Agent