Good ideas. Le dim. 2 mai 2021 à 21:03, Oleg Nenashev <[email protected]> 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 <[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 > <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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFNCU-8UfBjKZV51cHsvOeztPtqTftLr9GcVc7BhnAsqXpmAzw%40mail.gmail.com.
