Adopt Dynamic Search View plugin

[Kevin Martens]

Hi there,

I was hoping that I could adopt the Dynamic Search View plugin. I've gone and submitted the PR for permissions update, and mentioned Oleg in the PR, as he is currently listed as a maintainer. The plugin does show the "up for adoption" status, so please let me know if there is anything else I need to do.

- https://plugins.jenkins.io/dynamic-search-view/
- Plugin is up for adoption (Oleg is listed as a current maintainer)
- kmartens27 / https://github.com/kmartens27\
- https://github.com/jenkins-infra/repository-permissions-updater/pull/2786

--

Kevin Martens
Technical Content Developer

CloudBees, Inc.

E: kmar...@cloudbees.com

Pronouns: He/Him/His

[DuMaM]

Hi,
This is not connected with your request, but could we instead of drop this plugin in favor of https://github.com/jenkinsci/view-job-filters-plugin?
They both do the same job so I see no point in keeping two similar plugins.

[Mark Waite]

On Thursday, September 1, 2022 at 2:13:56 AM UTC-6 Nowak wrote:

Hi,
This is not connected with your request, but could we instead of drop this plugin in favor of https://github.com/jenkinsci/view-job-filters-plugin?
They both do the same job so I see no point in keeping two similar plugins.

We don't drop plugins unless there is a compelling case to drop the plugin.  For example, the security team sometimes stops distribution of plugins due to security risks.  Otherwise we allow plugins to continue distribution so that we do not disturb the users of that plugin.  Functional overlap is not a 

Since you noted that this is not connected with the request to adopt the plugin, can you confirm that you do not object to the adoption request?

Mark Waite

[DuMaM]

Hi,

I don't mind it, but it's up to main core maintainers not me :)
I'm only trying to point out that restoring plugin which duplicates work of other one (more popular one) is kind of waste of money and man resources.
I would rather focus on improving existing and more popular plugins instead.

> We don't drop plugins unless there is a compelling case to drop the plugin. 
> For example, the security team sometimes stops distribution of plugins due to security risks. 
> Otherwise we allow plugins to continue distribution so that we do not disturb the users of that plugin. Functional overlap is not a 

Ok, I understand it. I think it worth to discuss elsewhere if such plugins shouldn't be archived or something.

Bart

[Basil Crow]

On Thu, Sep 1, 2022 at 9:56 AM Mark Waite <mark.ea...@gmail.com> wrote:
> We don't drop plugins unless there is a compelling case to drop the plugin.
> For example, the security team sometimes stops distribution of plugins due
> to security risks. Otherwise we allow plugins to continue distribution so
> that we do not disturb the users of that plugin. Functional overlap is not a

[concern].

Mark is absolutely correct that the current governance model allows for
functional overlap. Perhaps the most striking example of this is Yet Another
Docker Plugin. Another example can be seen in the various GitLab plugins.

On Thu, Sep 1, 2022 at 1:13 PM DuMaM <nowak.b...@gmail.com> wrote:
> I'm only trying to point out that restoring plugin which duplicates work of
> other one (more popular one) is kind of waste of money and man resources. I
> would rather focus on improving existing and more popular plugins instead.

[…]

> I think it worth to discuss elsewhere if such plugins shouldn't be archived
> or something.

I tend to agree with the sentiment expressed by Bartosz. I think our community
is stretched thin already even without duplicating effort. Personally, I would
rather see fewer high-quality plugins, as opposed to competing plugins with
different strengths and weaknesses. I recognize this is a subjective preference
and others may disagree.

Bartosz, one of the reasons that situations like this persist for years is the
lack of interest in cleaning up previous efforts. Is this an area where you are
interested in volunteering? If so, I would encourage you to come up with ideas
about how we could make the situation better and discuss them either on this
list, on the community forum, or with the governance board, as appropriate.
There is definitely room for improvement, and we would welcome any efforts in
this area so long as the appropriate process is followed, including discussion
and approval for any governance changes.

Basil

[Kevin Martens]

My intention with adopting this plugin is more for the preparation of DevOps world than anything else. 

I am not a proper developer in this scenario, but am trying to go through the process of adoption as a new Jenkins contributor.

In doing so, I will be assisting with the DevOps world contributor summit, and want to ensure I'm providing the best help that I can.

Kevin

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjqoV9y7kMWGahbP0p1_79HeHTJiSgEgXD0GLhKQB2bA3A%40mail.gmail.com.

[DuMaM]

Hi,

>> My intention with adopting this plugin is more for the preparation of DevOps world than anything else. 

>> I am not a proper developer in this scenario, but am trying to go through the process of adoption as a new Jenkins contributor.

>> In doing so, I will be assisting with the DevOps world contributor summit, and want to ensure I'm providing the best help that I can.

That's good idea, but I can think of some better examples, which are still widely use across Jenkins Community and they need some attention.
Like this one (fairly simple plugin):
https://plugins.jenkins.io/badge/

Or: 

https://github.com/jenkinsci/extended-choice-parameter-plugin
I would be grateful if somebody could take care for this plugin. It looks like do to war in Ukraine maintainer is unable to take care of it and any work stopped in this sad day :(

Or some plugins which are serves as common dependencies (but can be hard):
https://plugins.jenkins.io/jaxb/
https://plugins.jenkins.io/docker-plugin/
https://plugins.jenkins.io/docker-java-api/
https://plugins.jenkins.io/apache-httpcomponents-client-4-api/

I think first option is the best one for start.

>> I tend to agree with the sentiment expressed by Bartosz. I think our community

>> is stretched thin already even without duplicating effort. Personally, I would
>> rather see fewer high-quality plugins, as opposed to competing plugins with
>> different strengths and weaknesses. I recognize this is a subjective preference
>> and others may disagree.

I agree in 120%.

>> Bartosz, one of the reasons that situations like this persist for years is the
>> lack of interest in cleaning up previous efforts. Is this an area where you are
>> interested in volunteering? If so, I would encourage you to come up with ideas
>> about how we could make the situation better and discuss them either on this
>> list, on the community forum, or with the governance board, as appropriate.
>> There is definitely room for improvement, and we would welcome any efforts in
>> this area so long as the appropriate process is followed, including discussion
>> and approval for any governance changes.

I would like to, but due to personal reasons I'm unable to focus on it till next year.
So for now I can't promise anything. 
Anyway I saw in meeting recordings that there is already some movement in creation of plugin scoring system.
It can be a good starting point.

Bart

[Mark Waite]

On Thursday, September 1, 2022 at 2:57:57 PM UTC-6 Bart wrote:

Hi,

>> My intention with adopting this plugin is more for the preparation of DevOps world than anything else. 

>> I am not a proper developer in this scenario, but am trying to go through the process of adoption as a new Jenkins contributor.

>> In doing so, I will be assisting with the DevOps world contributor summit, and want to ensure I'm providing the best help that I can.

That's good idea,

Thanks for your interest.  It is much appreciated.  Kevin is acting as a test case for a workshop and a draft jenkins.io tutorial that we're creating to help others adopt plugins.  He's not a Java developer.  He's not likely to continue as a maintainer of this plugin for the long term.  He's helping us develop the workshop by using his technical skills to review a tutorial ("Improve a plugin" tutorial visible on a preview site) that is being prepared for www.jenkins.io in a draft pull request.  We thought that it was better for him to temporarily adopt a lower use and lower risk plugin as part of the exercise.

We're happy to have others assist as well.  However, suggesting that Kevin should adopt a heavily used plugin and become the permanent maintainer is not what is expected from this exercise.

 

but I can think of some better examples, which are still widely use across Jenkins Community and they need some attention.
Like this one (fairly simple plugin):
https://plugins.jenkins.io/badge/

The badge plugin has recently been adopted as part of this preparation for the DevOps World workshop and the jenkins.io tutorial.  Because the adoption is expected to be temporary, we're not removing the badge plugin or other temporarily adopted plugins from the "adopt this plugin" list.  However, improvements have already started on the temporarily adopted plugins The badge plugin pull request queue has been cleared.  Other plugins that are being temporarily adopted are receiving similar improvements.  We plan to create one or more pull requests to those plugins to modernize them as preparation for our DevOps World workshop.  We hope that one of the results of the workshop will be that someone will choose to adopt one or more of those plugins long term.  If no one chooses to adopt the plugins long term, the plugins will still have benefited from our preparatory work.

 

Or: 

https://github.com/jenkinsci/extended-choice-parameter-plugin
I would be grateful if somebody could take care for this plugin. It looks like do to war in Ukraine maintainer is unable to take care of it and any work stopped in this sad day :(

The extended choice parameter plugin is not up for adoption.  It would require either approval from the maintainer or a two week waiting period before it could be adopted.  

The extended choice parameter plugin has 4 known security vulnerabilities.  Resolving known security vulnerabilities is outside the scope of the workshop.  We've intentionally dropped some plugins from our temporary adoption because they have open security vulnerabilities.

 

Or some plugins which are serves as common dependencies (but can be hard):
https://plugins.jenkins.io/jaxb/
https://plugins.jenkins.io/docker-plugin/
https://plugins.jenkins.io/docker-java-api/
https://plugins.jenkins.io/apache-httpcomponents-client-4-api/

I think first option is the best one for start.

We've intentionally not adopted the library plugins like jaxb, docker-java-api, and apache-http-components because the workshop and the tutorial are focused on plugins that contain Java source code.  The library plugins bundle jar files that are provided by other projects.  That makes their adoption and maintenance activities different than the more typical plugin adoption.

 

Mark Waite