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

[Gerald Combs <gerald@xxxxxxxxxxxxx>]

On 8/1/20 4:49 AM, Graham Bloice wrote:
> 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.

Is there any reason we shouldn't update the SubmittingPatches page itself? I'm assuming that we'll keep instructions on that page after the migration. Searching for "gerrit" on the wiki turns up the following pages that will need updating:

https://wiki.wireshark.org/Development/SubmittingPatches/Git-Review
https://wiki.wireshark.org/Development/SubmittingPatches
https://wiki.wireshark.org/Development/Workflow
https://wiki.wireshark.org/Development/SubmittingPatches/GitForWindows
https://wiki.wireshark.org/Development/Backporting

The following WSUG chapters will need updating as well:

docbook/wsdg_src/WSDG_chapter_userinterface.adoc
docbook/wsdg_src/WSDG_chapter_sources.adoc
docbook/wsdg_src/WSDG_chapter_tools.adoc

I had proposed migrating the wiki on the 10th (today) below, but that didn't happen. I've set aside some time to do that tomorrow. I'll work on documentation updates after that.

> 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?

When you push to a new branch in your forked repository on gitlab.com, the web UI will detect the change and show a "Create merge request" button:

https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html#create-merge-request-button

There are a bunch of command line clients available. I haven't used any of them, so any recommendations would be welcome:

https://gitlab.com/wireshark/gitlab-migration/-/wikis/Code-Review-(Gerrit)#command-line-clients

>  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.
Not that I'm aware, but there's an open issue at

https://gitlab.com/gitlab-org/gitlab/-/issues/22639

If I search for a commit hash in the migration repository's web UI, it returns a link to the MR.

>  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.

There's an open issue for this at

https://gitlab.com/gitlab-org/gitlab/-/issues/761

with several people mentioning Gerrit's CR-2 feature. GitLab does have an "All discussions must be resolved" setting for merge requests, which might work.

>  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?

I've requested a Gold plan via https://about.gitlab.com/solutions/open-source/.

>  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?

I had assumed that we would, since seems to be fairly standard in GitLab and GitHub. We'll be using GitLab's shared runners, so the abuse potential should be the same as for other projects. 

>  6. Bug attachments. The misc issues page (https://gitlab.com/wireshark/gitlab-migration/-/wikis/Miscellaneous-Migration-Issues) note problems, have these been resolved?

The issue is that the API supports uploading attachments, but doesn't currently support iterating through them. We should be able to work around this by fetching the issues and looking for attachment markup.

>  7. ??? Stuff I have no idea about yet.
> 
> 
> On Sat, 1 Aug 2020 at 00:01, Gerald Combs <gerald@xxxxxxxxxxxxx <mailto: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 <http://gitlab.com> URL and logo (SaaS) or a wireshark.org <http://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 <http://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
> 
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives:    https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>