Skip to content

Latest commit

 

History

History
154 lines (115 loc) · 6.64 KB

README.adoc

File metadata and controls

154 lines (115 loc) · 6.64 KB
Raw

JEP-11: Process improvements for adopting a Jenkins plugin

Table 1. Metadata

JEP

11

Title

Process improvements for adopting a Jenkins plugin

Sponsor

Craig Rodrigues

Status

Draft 💬

Type

Process

Created

2018-08-25

BDFL-Delegate

TBD
Table of Contents

Abstract

Over time, Jenkins plugin maintainers need to change as the original maintainer may need to move on to other work. Adopt a Plugin outlines the process for adopting a plugin. This page mentions that the Jenkins developer mailing list should be e-mailed to start the process. This JEP proposes some process improvements to adopting a plugin.

Specification

Existing plugin adoption process

The existing plugin adoption process is outlined on this page.

The above web page can be summarized as follows.

For a user who is interested in adopting a plugin:

  1. The user should visit the plugin site for a list of plugins eligible for adoption.

  2. The user should review the documentation on plugin maintainership in the Jenkins project, especially documentation with respect to plugin compatibility and marking a plugin as incompatible with older Jenkins releases.

  3. The user should mail the Jenkins Developers mailing list and request to be made a maintainer of the plugin. The user is encouraged to CC: the existing maintainer during this e-mail request. In the e-mail, the user is encouraged to submit their GitHub ID and Jenkins infrastructure ID.

  4. If the existing maintainer provides feedback agreeing to the request, the Jenkins infrastructure admins will usually grant maintainership of the plugin to the user.

  5. Sometimes an existing maintainer cannot be contacted, or does not respond in a timely way to agree or disagree with the request to change maintainership of the plugin. In these cases, if the existing maintainer does not provide feedback after approximately two weeks, the Jenkins infrastructure admins will usually grant maintainership of the plugin to the user.

  6. Once granted maintainership of the plugin, the user is encouraged to file a GitHub PR against link:https://github.com/jenkins-infra/repository-permissions-updater to request permission to deploy snapshots and releases of the plugin.

For a maintainer who is interested in giving up maintainership of a plugin:

  • The maintainer should edit the plugin’s GitHub repo page and add the adopt-this-plugin label.

Proposed modification to plugin adoption process: using JIRA

  • When someone wants to adopt a plugin, they should file a JIRA ticket.

  • They should set the Component field to the name of the plugin.

  • In addition, they must set a tag in JIRA to adopt-plugin.

  • The current plugin maintainer will receive an e-mail from JIRA. If there are multiple plugin maintainers, they should be mentioned via the "@" mechanism in JIRA.

  • If the plugin owner does not respond to the JIRA ticket within 3 weeks (enough time to cover reasonable vacation time, sick time, emergency), then the plugin can be adopted.

  • Plugin authors will also be able to file a JIRA ticket with the adopt-plugin tag, and mention that they want to give up maintainership of the plugin By doing things in JIRA, it is easier for Jenkins administrators to query the list of plugins which are up for adoption and there is a clear audit trail of when a plugin was adopted.

Post plugin adoption tasks

  • The new maintainer needs to be given write access to the git repository with the plugin code. This can by done by sending special commands to the bot on the IRC Freenode #jenkins channel.

  • In JIRA, the new maintainer should be made the default assignee for tickets filed with Component set to that plugin.

  • In JIRA, all Unresolved tickets should be assigned to the new maintainer.

  • The new maintainer will be responsible for updating the wiki page for the plugin to list themselves as the new maintainer.

  • The new maintainer must updat the pom.xml metadata for the plugin in GitHub to indicate that they are the new maintainer.

Motivation

Due to the popularity of Jenkins, the mailing lists receive a lot of messages. For casual Jenkins users who maintain plugins, following the mailing lists may be difficult and it is easy to miss these types of e-mails.

There must be a clear process by which a user can easily request to adopt a plugin. This process must have a clear audit trail that can be tracked. There also must be a clear way to track the post plugin adoption tasks.

Reasoning

⚠️

(jglick) A lot of minor refinements or alternative structures were discussed on the dev list. You might not agree with any of them, but the basic ideas ought to be noted in this section and an explanation given of why you are going with the current proposal instead.

Backwards Compatibility

There are no backward compatibility concerns.

Security

There are no new security risks introduced by this proposal. The existing plugin adoption process theoretically makes it possible for bad actors to take control of popular, but badly maintained plugins. The Jenkins infra team should take this into account when reviewing requests to change plugin maintainership, and deny requests to bad actors. This JEP does not offer any other solutions to this problem.

Infrastructure Requirements

⚠️

(jglick) There is no preparation needed. The first time a new tag is typed in, it becomes available in completion.

Testing

There are no testing issues related to this proposal.