Add markewaite as a zoom plugin maintainer

[MarkEWaite]

Add markewaite as a zoom plugin maintainer

JENKINS-76442 reports a class not found exception in the Zoom plugin due to a class loading issue with the Jackson 2 API plugin. The issue is confirmed resolved by pull request:

• [JENKINS-76442] Fix class not found exception jenkinsci/zoom-plugin#23

When I submitted the pull request, I mentioned @ZeyuCai-ZOOM and @LukasLuZoom asking them to merge and release the pull request so that other users of the Zoom plugin could receive the fix. There has been no response to that request in the last week.

Yesterday I sent email to the zoom_us email address from issues.jenkins.io.

I would like to be added as a maintainer so that I can merge and release pull request:

• [JENKINS-76442] Fix class not found exception jenkinsci/zoom-plugin#23

That pull request replaces several other pending pull requests on the plugin, including:

• chore(pom): Use recommended core version 2.462.3, and Java 11. jenkinsci/zoom-plugin#22
• feat(java): Require Jenkins core 2.492.3 and Java 17 jenkinsci/zoom-plugin#21
• Require 2.346.3 jenkinsci/zoom-plugin#20
• Bump junit from 1.3 to 1159.v0b_396e1e07dd jenkinsci/zoom-plugin#15
• Bump jackson-databind from 2.9.10.4 to 2.12.7.1 jenkinsci/zoom-plugin#14
• Bump httpclient from 4.5.6 to 4.5.13 jenkinsci/zoom-plugin#9

I do not intend to add new features to the plugin. I plan to merge the one pull request, close the pull requests that it replaces, and take the necessary steps to switch the plugin to use automated releases.

Link to GitHub repository

https://github.com/jenkinsci/zoom-plugin

Existing team members to approve this pull request:

• @ZeyuCai-ZOOM
• @LukasLuZoom

I would prefer that they merge and release the fix so that I don't need to become a maintainer of the plugin. However, if they don't merge and release the fix, then it is better that I become a maintainer instead of requiring multiple users to install the incremental build with the fix. Installing an incremental build is more complicated and the incremental build will only remain in our artifact repository for 3 months before it is deleted.

When modifying release permission

List the GitHub usernames of the users who should have commit permissions below:

• @markewaite

This is needed in order to cut releases of the plugin or component.

If you are modifying the release permission of your plugin or component, fill out the following checklist:

Release permission checklist (for submitters)

• The usernames of the users added to the "developers" section in the .yml file are the same the users use to log in to accounts.jenkins.io.
• All users added have logged in to Artifactory and Jira once.
• I have mentioned an existing team member of the plugin or component team to approve this request.

When enabling automated releases (cd: true)

Follow the documentation to ensure, your pull request is set up properly. Don't merge it yet.
In case of changes requested by the hosting team, an open PR facilitates future reviews, without derailing work across multiple PRs.

Link to the PR enabling CD in your plugin

CD checklist (for submitters)

• I have provided a link to the pull request in my plugin, which enables CD according to the documentation.

Reviewer checklist

• Check that the $pluginId Developers team has Admin permissions while granting the access.
• In the case of plugin adoption, ensure that the Jenkins Jira default assignee is either removed or changed to the new maintainer.
• If security contacts are changed (this includes add/remove), ping the security officer (currently @Wadeck) in this pull request. If an email contact is changed, wait for approval from the security officer.

There are IRC Bot commands for it.