Duties of a plugin maintainer.

[iamagui]

Hi all,

I am very new to Jenkins and came across that 'https://plugins.jenkins.io/cvs/' is up for adoption. If possible, could you please let me know the duties and responsibility of a plugin maintainer to see whether l can able to perform the tasks and able to adopt it. Pardon me if asking this already disqualify me for being a maintainer. Thanks in advance.

[Mark Waite]

On Sunday, March 5, 2023 at 9:00:20 AM UTC-7 iamagui wrote:

Hi all,

I am very new to Jenkins and came across that 'https://plugins.jenkins.io/cvs/' is up for adoption. If possible, could you please let me know the duties and responsibility of a plugin maintainer to see whether l can able to perform the tasks and able to adopt it. Pardon me if asking this already disqualify me for being a maintainer. Thanks in advance.

Thanks for your interest and thanks for a great question.

I think that our documented answer(s) are missing key information.  I'll point to the documentation that I've found and then offer my opinions as a plugin maintainer.

Documentation that I've found:

https://www.jenkins.io/project/governance/#helping-and-taking-over-dormant-plugins provides a few sentence overview that encourages plugin adoption, but it does not outline specific duties of a plugin maintainer.

https://www.jenkins.io/doc/developer/plugin-governance/adopt-a-plugin/#faq includes text that says:

 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.

Unfortunately, the "documentation on plugin maintainership" phrase is not a link and I don't find a specific single document that I would call the "documentation on plugin maintainership".  I think we should create that page and I will attempt to make this post be a rough draft of the things that I think should be described there.

My opinions as a plugin maintainer:

I believe there are multiple levels of involvement and a plugin maintainer helps users if they engage in any of those levels.  They may not be able to engage in all of them, but any of them are already a help to Jenkins users

1. Test and release new versions of the plugin (either manually or automatically) when valuable and relevant changes have been made to the plugin
2. Modernize the plugin (see the "Improve a plugin" tutorial for guidance and the "Contributing to open source" document for other ideas) and release a version with the modernizations
3. Review, approve, and merge dependency update pull requests (usually from Dependabot), releasing new versions when those updates include important changes
4. Respond to plugin security issues when  the security team shares issues (see the security guide for maintainers)
5. Respond to new issue reports
   
6. Review existing (CVS plugin) issue reports
   
7. Fix issues
   
8. Review existing (CVS plugin) pull requests and provide feedback to the submitters on those pull requests
9. Implement enhancements

If all a new maintainer can do is test and release new versions of the plugin, they've helped users by delivering updates.  If they can also modernize the plugin and release a new version, they've also helped users and reduced their future work as a maintainer.  If they can also review existing issue reports, that's even more that they have helped users.

Mark Waite

[iamagui]

Many thanks Mark, much appreciated. I will get back in a week or so, thanks again.

[Basil Crow]

The main duty of a plugin maintainer from my perspective is to not
introduce regressions for users of the plugin.

[Jiri Vanek]

On 3/8/23 04:31, Basil Crow wrote:
> The main duty of a plugin maintainer from my perspective is to not
> introduce regressions for users of the plugin.
>

Interesting point of view. How about this scenario:
- plugin is maintained
- I do a PR, adding enhancements
- plugin maintainers suggest changes, which actually made regression in plugin
- I highlight that, I implement that
- year of silence, suddenly the plugin is orphaned
- Should I merge my own PR with suggested "regressing" changeset, which was recommended by former maintainers or - as by your advice - roll back to original idea code?

Especially junior (and all lazy ones) contributors would definitely follow recommended path, rather then roll back.

Another idea - to adopt a plugin usually mean that you are heavily using it. That also usually means that you have some changes in mind, worthy of implementation. And suddenly there is no gate keeper to calm down yours enthusiasm, so it is
easy to cause regression which may be hard to fix.

Maye to rephrase your sentence:
"The main duty of a plugin maintainer is to enjoy the maintenance. It is also important to keep plugin secure, up to date with future jenkins and java. In unlikely case regressions for users of the plugin happens, then to fix it, or at
least workaround it"

Thanx all for amazing job around jenkins you do.

J.

--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09

[Mark Waite]

On Wednesday, March 8, 2023 at 1:29:53 AM UTC-7 Jiri Vanek wrote:

On 3/8/23 04:31, Basil Crow wrote:
> The main duty of a plugin maintainer from my perspective is to not
> introduce regressions for users of the plugin.
>

Interesting point of view. How about this scenario:
- plugin is maintained
- I do a PR, adding enhancements
- plugin maintainers suggest changes, which actually made regression in plugin
- I highlight that, I implement that
- year of silence, suddenly the plugin is orphaned
- Should I merge my own PR with suggested "regressing" changeset, which was recommended by former maintainers or - as by your advice - roll back to original idea code?

Since even experienced maintainers make mistakes and a regressing changeset is generally a mistake, I think you should use the original idea code, since it is better for you and better for other users.

 

Especially junior (and all lazy ones) contributors would definitely follow recommended path, rather then roll back.

I made that mistake with a plugin that I adopted a few months ago.  It's last release had been done many years ago.  I adopted it and made the flawed assumption that the master branch was in good condition, ready to release.  I released a new version of the plugin from the master branch and was then dismayed to have reports from users that the new release included a regression.  I reverted most of the changes that had been made on the master branch in those intervening years and released a new version of the plugin without those regressions.  The existing use cases were much more valuable than the new features that introduced the regression.

I think that users were ultimately benefited by the new releases of the plugin, though the regression was a disruption that would have been better to avoid.

 

Another idea - to adopt a plugin usually mean that you are heavily using it. That also usually means that you have some changes in mind, worthy of implementation. And suddenly there is no gate keeper to calm down yours enthusiasm, so it is
easy to cause regression which may be hard to fix.

I think that is an acceptable risk, especially if the new maintainer is an active user of the plugin.  The new maintainer is more likely to respond to reports of a regression than others are.  The enthusiasm of the new maintainer moves the plugin forward, even if some of that forward motion may be accompanied by an occasional unintended partial step backwards

I didn't find it difficult to revert the changes and fix the regression in the case that I created.

 

Maye to rephrase your sentence:
"The main duty of a plugin maintainer is to enjoy the maintenance. It is also important to keep plugin secure, up to date with future jenkins and java. In unlikely case regressions for users of the plugin happens, then to fix it, or at
least workaround it"

I like the idea of including a comment about enjoying the maintenance effort.  Thanks for suggesting it.

Mark Waite

[Basil Crow]

On Wed, Mar 8, 2023 at 5:13 AM Mark Waite <mark.ea...@gmail.com> wrote:
> I made that mistake with a plugin that I adopted a few months ago. It's last
> release had been done many years ago. I adopted it and made the flawed
> assumption that the master branch was in good condition, ready to release. I
> released a new version of the plugin from the master branch and was then
> dismayed to have reports from users that the new release included a
> regression. I reverted most of the changes that had been made on the master
> branch in those intervening years and released a new version of the plugin
> without those regressions.

Worse, I once adopted a plugin whose previous maintainer had not merged a
security fix back to the main branch, meaning that releasing the main branch
would have reintroduced the security issue. Thankfully, I noticed that before
doing a release. In general, I would advise new maintainers to carefully review
the diff from the last release up until the current point in time to ensure that
they are prepared to deal with any regressions when doing the next release.

[iamagui]

Mark et al.,

Apologies for the very late reply.

I am NOT even a part-time developer, l develop small things required for my work.

The main reason I wanted to adopt this plugin is: 7 years ago, I was the build and release engineer for a development team which used CVS. Now git is used with jenkins. While working with (git) plugins, I remembered CVS. So checked and it was up for adoption. Thought I could help my good ol CVS. I come from a mechanic(al) background, so assumed maintenance means dusting, water wash, etc.,. but looks more to it.

Many thanks again Mark for sharing the 'Contributing to Open Source' document right away. Just started watching the first video also. Once I am done with all the videos, l hope to get a grip.

l will get back to you if l can help with the maintenance.

Apologies again.