Good ideas. Le dim. 2 mai 2021 à 21:03, Oleg Nenashev <o.v.nenas...@gmail.com> a écrit :
> Hi Arnaud, > > One if the options would be to set a borderline quality/devtools > requirement. For example, we can say that a plugin "must use Plugin POM 3.7 > or above" (Java 11 devflow for Maven, ??? Gradle) or "a plugin should be > built and tested against Jenkins 2.7.1 LTS at least". Such a requirement > should cover almost all active and "active" plugins. > > BR, Oleg > > On Sun, May 2, 2021, 20:24 Arnaud Héritier <aherit...@gmail.com> wrote: > >> I love all these proposals and I'll support them. >> What is clearly important is to have some well defined rules and if >> potentially to automate as much as possible the processes required to >> follow the plugins lifecycle. >> >> I am not sure if it could make sense or not, but could we have some cases >> (plugins used as library maybe?) where not having any (or a lot) of >> activity could not be an issue ? >> >> On Sun, May 2, 2021 at 4:06 PM Oleg Nenashev <o.v.nenas...@gmail.com> >> wrote: >> >>> I definitely support having a policy for putting for adoption, >>> deprecation and then removal. Before we introduce this policy, I would like >>> to firstly introduce a concept of the "company/team owner" so that we could >>> distinguish plugins maintained by company contributors and contact >>> companies instead of individuals who might have left their employer via >>> inactive emails. After we do so, +100 for setting up a policy as long as >>> there are manual gates for the community approval. Some plugins "just work" >>> afterall, and maintainers may not need to deliver patches. >>> >>> I would propose the following: >>> >>> - The plugins will be put for adoption after 1 year of maintainer >>> inactivity, if there are open pull requests without changes requested by >>> maintainer (approved but not merged OR unreviewed). If possible, GitHub >>> maintainers should do the best effort attempt to reach out to the >>> maintainer (GitHub ping and email if available in pom.xml or Jira). >>> Adoption is marked via the "adopt-this-plugin" topic in GitHub and >>> propagated to the update center. To recover from this stage, the Plugin >>> Adoption process is applied >>> - The plugin may be marked as deprecated after 1 year in adoption OR >>> once there are known unresolved breaking changes in the Jenkins weekly >>> baseline. To recover from this stage, there should be plugin adoption. >>> Deprecation is marked via the "deprecated" repo topic in GitHub and >>> propagated to the update center. >>> - After 6 months of being deprecated, the plugin may be depublished. >>> The source code will be archived in this case. To recover from this >>> stage, >>> a plugin needs to be adopted by the maintainer and then released as a new >>> version. After that, it may be restored by a pull request to the update >>> center repo >>> >>> Multi-plugin repositories might be managed by the same process, because >>> all of them will be put for adoption or depublished at once. Deprecation is >>> a bit trickier, but we have a way to control that in the update center >>> metadata if needed. >>> >>> For such a process, it would be also great to finally support the >>> tombstone pages for depublished plugins on the plugin site. They could >>> provide plugin users with information about how to step up and to recover >>> the plugin. >>> >>> Best regards, >>> Oleg Nenashev >>> >>> >>> >>> >>> >>> >>> >>> On Wednesday, April 28, 2021 at 11:21:00 AM UTC+2 raihaan...@gmail.com >>> wrote: >>> >>>> We should have an EOL policy as it stands we make breaking changes to >>>> Jenkins where plugins that have not been released recently are effectively >>>> disregarded. >>>> We need to set a clear line where we believe its ok to break a plugin >>>> which can perhaps be part of this EOL policy. >>>> >>>> For an EOLed plugin we could use a similar approach to plugin adoption. >>>> Where the maintainer has the option of now fixing up the possible problems >>>> with the plugin and release a new version. Which would reset its EOL >>>> countdown. >>>> >>>> Cheers, >>>> Raihaan >>>> On Tuesday, 27 April 2021 at 15:29:46 UTC+8 bma...@gmail.com wrote: >>>> >>>>> Oh, and: given the nature of our project, I think defining a clear way >>>>> to un-EOL a plugin would likely be needed too. >>>>> It's probable that we'll EOL some plugins, and after say 1 or 2 years >>>>> some folks will want to revive some of the plugins that got EOLed. >>>>> >>>>> It may seem backward, but I think it's a healthy thing. The bottom >>>>> line and expectation is that anyway we'll probably EOL dozens of plugins >>>>> quickly and only a handful will be requested to be unEOLed (meaning, after >>>>> a transitional pre-EOL warning period and nobody has complained during >>>>> this >>>>> one). >>>>> >>>>> -- Baptiste >>>>> >>>>> Le mar. 27 avr. 2021 à 09:24, Baptiste Mathus <m...@batmat.net> a >>>>> écrit : >>>>> >>>>>> I agree this is an initiative definitely worth pursuing. We all know >>>>>> this is a pain. >>>>>> >>>>>> On criteria for defining whether a plugin should be EOLed, I think >>>>>> the best idea I have seen so far was Stephen's: >>>>>> >>>>>> https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/jenkinsci-dev/Ih0RviQ0G90/NmoVJQ1j6NAJ >>>>>> >>>>>> Basically automated regular PRs allowing for a global detection of >>>>>> plugins without an active maintainer. >>>>>> That maintainer's existence/reactivity + some criteria TBD (like last >>>>>> release date, the number of open jira issues, etc.) would help us decide >>>>>> whether or not start an EOL process. >>>>>> >>>>>> Anyway, however we define these criteria, which discussion I think we >>>>>> can handle separately, defining an EOL process I think has become vital >>>>>> indeed for the Jenkins Project to keep thriving. >>>>>> >>>>>> >>>>>> Le mar. 27 avr. 2021 à 04:00, Basil Crow <m...@basilcrow.com> a >>>>>> écrit : >>>>>> >>>>>>> Abandoned plugins cause friction for both Jenkins users and >>>>>>> contributors >>>>>>> alike. >>>>>>> >>>>>>> They cause friction for users because they are unlikely to be >>>>>>> simpatico >>>>>>> with newer features like Pipeline. In the worst case, they are >>>>>>> downright >>>>>>> incompatible with newer features like Configuration Form >>>>>>> Modernization >>>>>>> and cause breakage that is difficult for users to resolve. >>>>>>> >>>>>>> They cause friction for contributors by making it difficult to >>>>>>> perform >>>>>>> project-wide changes, such as Configuration Form Modernization or >>>>>>> dependency updates. >>>>>>> >>>>>>> True, distributing as many plugins as possible for as long as >>>>>>> possible >>>>>>> maximizes the value the project provides and maintains the project's >>>>>>> strong reputation for flexibility. Yet, treating abandoned plugins as >>>>>>> first-class citizens indefinitely carries a non-trivial cost, and >>>>>>> that >>>>>>> cost only increases the longer a plugin remains abandoned. >>>>>>> >>>>>>> The project is over 15 years old, and some plugins have been >>>>>>> abandoned >>>>>>> for the better part of a decade. Many of these plugins will likely >>>>>>> remain abandoned for the next decade. At what point does the cost of >>>>>>> carrying these plugins outweigh the benefit? >>>>>>> >>>>>>> I do not know the answer, but I do know that the answer is not >>>>>>> "never". >>>>>>> Contributor bandwidth is a finite resource. However, there remain >>>>>>> hundreds of plugins that have been abandoned for the better part of a >>>>>>> decade yet are seemingly presented as first-class citizens without so >>>>>>> much as a deprecation notice. This does not seem sustainable. >>>>>>> >>>>>>> I would like to propose that we define a process for plugin >>>>>>> end-of-life: >>>>>>> initially marking such plugins as deprecated, then eventually >>>>>>> removing >>>>>>> such plugins from distribution. >>>>>>> >>>>>>> How would we decide when to deprecate a plugin or remove it from >>>>>>> distribution? We could use metrics such as the number of days since >>>>>>> the >>>>>>> last release and the number of installations. For example, we could >>>>>>> declare that any plugin that has not been released in five years >>>>>>> would >>>>>>> be automatically deprecated and that any plugin that has remained >>>>>>> deprecated for more than five years would be removed from >>>>>>> distribution. >>>>>>> We could put escape hatches in place to exempt sufficiently popular >>>>>>> plugins from this policy. >>>>>>> >>>>>>> I do not have a strong preference as to how long the support window >>>>>>> should be. But I do have a strong preference that it be finite: >>>>>>> supporting an unbounded number of plugins as first-class citizens >>>>>>> for an >>>>>>> unbounded amount of time does not seem sustainable. >>>>>>> >>>>>>> I can already hear Oleg calling for a blog post to be written >>>>>>> announcing >>>>>>> such a policy months in advance of its implementation, were such a >>>>>>> policy to be agreed upon. That would be fine by me as well. Again, >>>>>>> the >>>>>>> point is not to be overly aggressive or to surprise users, but >>>>>>> rather to >>>>>>> put reasonable limits in place that support the project's long-term >>>>>>> goals given the finite resources that are available. >>>>>>> >>>>>>> -- >>>>>>> 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/CAFwNDjoNMRbkDdkcjYMZSauCfE%2BRQ6pkv_jGG5W2RTqaDiJM2w%40mail.gmail.com >>>>>>> . >>>>>>> >>>>>> -- >>> 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/9a95b122-46d7-489c-8a87-a292eed23d71n%40googlegroups.com >>> <https://groups.google.com/d/msgid/jenkinsci-dev/9a95b122-46d7-489c-8a87-a292eed23d71n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> >> >> -- >> Arnaud Héritier >> Twitter/Skype : aheritier >> >> -- >> > You received this message because you are subscribed to a topic in the >> Google Groups "Jenkins Developers" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/jenkinsci-dev/9M2B6ZTKjI0/unsubscribe. >> To unsubscribe from this group and all its topics, 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/CAFNCU-9pOooHOaBkOTLZdyOgDKSnXLXH1b6J6cRC%3DZPZPL51aA%40mail.gmail.com >> <https://groups.google.com/d/msgid/jenkinsci-dev/CAFNCU-9pOooHOaBkOTLZdyOgDKSnXLXH1b6J6cRC%3DZPZPL51aA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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/CAPfivLA8du0_%3DcbEnvDiGyBtVfYe0kieQV1BBsPH%2B%3DW2CENQ4A%40mail.gmail.com > <https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLA8du0_%3DcbEnvDiGyBtVfYe0kieQV1BBsPH%2B%3DW2CENQ4A%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- Arnaud Héritier Twitter/Skype : aheritier -- 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/CAFNCU-8UfBjKZV51cHsvOeztPtqTftLr9GcVc7BhnAsqXpmAzw%40mail.gmail.com.
