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 <ger...@wireshark.org > <mailto:ger...@wireshark.org>> 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@wireshark.org> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe > ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
