Wireshark-dev: [Wireshark-dev] GitLab update and migration timeline

From: Gerald Combs <gerald@xxxxxxxxxxxxx>
Date: Fri, 31 Jul 2020 15:59:56 -0700
I think we're finally ready to start migrating our code review, bug/issue tracking, and wiki infrastructure to GitLab. The bug to issue conversion scripts preserve bug metadata, comments, and attachments, and prettifies markup where it can. The wiki conversion script preserves markup and attachments. A test repository with output from the bug/issue and wiki migration scripts can be found at

https://gitlab.com/wireshark/migration-test

A question I'd been dithering on way too long was choosing between GitLab's SaaS or hosting our own instance. The main difference on the front end would be between having a gitlab.com URL and logo (SaaS) or a wireshark.org URL and logo (self-hosted). The difference on the back end is much greater, since the self-hosted solution requires operating a GitLab instance and likely a Kubernetes cluster for runners. Much as I'd like to have a Wireshark-branded development site, it's just not worth the operational overhead and expense.

As a result, gitlab.com/wireshark/wireshark will be the next home of our repository, issue tracker, and wiki.

A repository for migration information and the migration scripts themselves can be found at

https://gitlab.com/wireshark/gitlab-migration/-/wikis/home

If you notice any conversion bugs in the wireshark/migration-test repository, please open an issue in the wireshark/gitlab-migration repository. For other issues (such as WSDG and Wiki content updates) it would probably make more sense to open a ticked in Bugzilla (or you can reply to this email, of course).

I've come up with the following tentative schedule for the migration:

* August 10. Migrate the wiki.

* August 12. 3.2.6, 3.0.13, 2.6.19 releases. Noted here for scheduling purposes.

* August 23. Migrate the main repository bugs/issues, aka The Big Switch.

* Unscheduled. Release and fuzz builder migration. 

The main repository + bug/issue migration will require a fair amount of downtime, so I scheduled it for a Sunday.