We’re looking for new maintainers of existing plugins!
This page addresses cases when there is no active maintainer of a plugin:
Adopting plugins marked for adoption. Plugin maintainers can mark plugins for adoption if they do not plan to maintain their plugins anymore. In such case we have a low-barrier process for taking over plugins.
Adopting abandoned plugins.
Sometimes plugin maintainers move on without marking plugins for adoption, due to various reasons.
In such case we can transfer ownership for plugins being hosted within the jenkinsci GitHub organization.
Such transfer may take a while. If a plugin has no maintainers listed then it follows the adoption process.
The procedure is two-fold:
Announce your adoption intention by mail
Send the notification email to the Jenkins Developers mailing list. Be sure to provide the following information:
Link to a plugin you want to adopt
The status of the plugin ("for adoption" or "abandoned")
Link(s) to pull requests you want to deliver, if applicable
Your GitHub username/id (e.g. oleg-nenashev for https://github.com/oleg-nenashev/)
Your Jenkins infrastructure account id. Create your account if you don’t have one.
The link to the "Repository Permission Updater" PR described below
Submit a PR on the "Repository Permission Updater" repository
File a pull request against Repository Permissions Updater (RPU) to be able to deploy releases for your plugin.
You need to update the plugin’s definition yaml file located in the permission directory.
Add your Jenkins infrastructure account under the developer section.
Refer to the Readme for detailed guidance.
Ping the current registered developers on the PR to inform them of your initiative (just in case they miss the notification on the Jenkins Dev List).
Once you have access to the plugin’s Github repository, be sure to remove the adopt-this-plugin label.
This can be done by clicking on the gear wheel near the "About".
Note: Membership of the jenkinsci github organization is required.
If this is not the case yet, you will receive an invitation sent to your GitHub email account.
You can also accept it at https://github.com/jenkinsci if you can’t find the invite.
Note that the invitation is valid for 7 days only.
If you need a new invitation because you missed it, replying on the RPU pull request is the easiest way. You can also create an INFRA helpdesk ticket or email the jenkinsci-dev mailing list.
For abandoned plugins, you are expected to try and reach out to existing maintainer(s) using a best effort. The typical way to do that is to ping in GitHub and to add her/his/their email addresses in CC (hint: Git commits should have this information). We typically wait for about 2 weeks in normal work periods before proceeding, so please be patient. Hence, if you can prove the existing maintainer already agrees and you explicitly asked about taking over (e.g. in a PR discussion), the process can be faster.
Once the situation is clarified, proceed as for a "adoptable" plugins (see above). On the notification email, add information about the steps taken to contact the existing maintainers.
If there are no maintainers listed in the "Repository Permission Updater" repository then there is no need to wait 2 weeks and it can proceed immediately.
No. Jenkins is designed with backward compatibility in mind, so it’s rare that a plugin stops working. And even then there’s often someone who can fix the bug and release a new version even if they wouldn’t be considered a maintainer of the plugin. So if you’re happy with what a plugin is offering, there’s no reason not to use it just because it’s up for adoption.
Check out the list of plugins up for adoption at the bottom of this page. If you see a plugin you like, visit its wiki page as it may contain additional information about the adoption request.
Once you’ve chosen a plugin, review the documentation on plugin maintainership in the Jenkins project. This is especially important if you’re not currently a plugin developer.
First, make sure the plugin is not being actively maintained. Even in actively maintained plugins, there may be periods of lower developer activity. Don’t misinterpret failures to respond to questions or requests as the plugin being unmaintained!
As a new maintainer of a new plugin, you’ll inherit its existing users, so be careful with breaking changes. We value data compatibility highly, so any new releases should remain compatible with previous data and upgrade smoothly. If you need help with this, don’t hesitate to ask other Jenkins developers for help. And if all else fails, you can mark a new version as being incompatible with older releases to warn users before they update.
Before marking a plugin for adoption, we recommend to announce the incoming change in the Jenkins Developer Mailing list or in other appropriate channels. It may help you to find new maintainers and, ideally, to establish a transition and knowledge transfer process.
Add the adopt-this-plugin label to the plugin. It can be done in 2 ways:
Put an adopt-this-plugin topic in the plugin’s GitHub repository.
If you have multiple plugins inside a single repository, it will apply to all of them
Add an adopt-this-plugin label to the plugin entry in the Update Center’s label-definitions.properties file
Optional: If you want to explain why you’re marking that plugin as up for adoption, add a section to the plugin’s documentation. You can also document your vision for the plugin there so that new maintainers can take it into account.
This status is based on the adopt-this-plugin or jenkins-adopt-this-plugin label in the update center.
Such labels can come from the topics in the plugin’s GitHub repository or from
the Update Center’s label-definitions.properties file.
If you remove these topics/labels, the adoption notice will disappear after the repo synchronization.