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 czwartek, 1 września 2022 o 22:33:19 UTC+2 kmar...@cloudbees.com napisał(a): > 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 > > > On Thu, Sep 1, 2022 at 4:28 PM Basil Crow <m...@basilcrow.com> wrote: > >> 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 >> >> -- >> 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 >> . >> > > > -- > Kevin Martens > Technical Content Developer > CloudBees, Inc. > > > E: kmar...@cloudbees.com > > Pronouns: He/Him/His > > -- 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-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/835994a6-137c-4e55-b265-b8465f937c85n%40googlegroups.com.
