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