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 <[email protected]> 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 <[email protected]> > 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 [email protected] >> 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 [email protected] 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 <[email protected]> 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 <[email protected]> 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 [email protected]. >>>>>> 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 [email protected]. >> 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 > [email protected]. > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLA8du0_%3DcbEnvDiGyBtVfYe0kieQV1BBsPH%2B%3DW2CENQ4A%40mail.gmail.com.
