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

[Graham Bloice <graham.bloice@xxxxxxxxxxxxx>]

Yes, I'm complaining about change, but as I have 0 previous exposure to GitLab some\many things are unclear to me. And I'm getting older and grumpier.

I think we need to create a new page similar to the Submitting Patches wiki page describing the workflow BEFORE we make the change.  The transition document at https://gitlab.com/wireshark/gitlab-migration/-/wikis/Code-Review-(Gerrit) partially describes things but leaves me confused.  If there is a new page and I've missed it, please can someone add a link to it on the Submitting Changes page with a banner indicating changes are imminent.

Things that are uncertain to me:

1. When submitting a change I have to do two seperate ops, a git push and then a manual op on the GitLab UI to create an MR, i.e. no tooling such as git review?  When creating the MR is my "source" repo remembered in some way or do I have to do lots of UI ops to locate it, potentially leading to user error?
2. Has the issue of no back reference from a commit message to the MR been resolved?  Maybe the GitLab UI has alternative support for this in some form, e.g. enter a commit hash to get the MR?  What I'm looking for is the workflow; what is this code doing -> git blame -> look at code review, bug report.
3. MR blocking.  I understand this is unsupported so we'll need some convention between core devs to not merge changes that another has pseudo blocked.
4. Presumably the Merge Request Reviews recently added to Core in 13.1 (https://about.gitlab.com/releases/2020/06/22/gitlab-13-1-released/#merge-request-reviews-moved-to-core) will make reviewing easier.  What GitLab "plan" will we be on in order to determine what features will be available?
5. Will the PD builders be auto-triggered? The Automated Builds page(https://gitlab.com/wireshark/gitlab-migration/-/wikis/Automated-Builds-And-Continuous-Integration-(Buildbot)) suggest they can\will.  Is there a potential for abuse there?
   
6. Bug attachments. The misc issues page (https://gitlab.com/wireshark/gitlab-migration/-/wikis/Miscellaneous-Migration-Issues) note problems, have these been resolved?
7. ??? Stuff I have no idea about yet.

On Sat, 1 Aug 2020 at 00:01, Gerald Combs <gerald@xxxxxxxxxxxxx> wrote:

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.

 

--

Graham Bloice