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/CANWgJS63_C0V1_eThB7Toiks2_a--vUxcRHtxbp23X8YVMzxjA%40mail.gmail.com.
