On Tue, Apr 27, 2021 at 4:00 AM Basil Crow <[email protected]> wrote:
> 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. > How was the config form change impacted by this specifically? It seems that we get the most complaints recently (i.e. once actively maintained plugins were identified and fixed) about that change for a plugin with unresolved security issues that we're not currently distributing, TFS. It doesn't look like this proposal would help here. > 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. Doing this also means we commit to "support" (whatever that means) anything not deprecated. I am not sure we want that. A major reason I added the release date to the UI on the plugin manager is to highlight to admins that they're (considering) using likely obsolete software. We're not (yet) exposing popularity on the UI other than for sort order, but the plugin site does. Between the two, it seems to me we give admins the tools they need to determine whether they want to continue using plugins that are likely unmaintained, and in case of problems they're likely to be the first ones (low install count). I would prefer if we'd consider a more expressive system for plugins metadata. We added 'deprecated' and 'adopt-a-plugin' labels to core recently, but every new label like that needs dedicated support. Something more extensible, with version ranges like we do for security warnings could help here: "This plugin is likely to break the UI once you update Jenkins to 2.277.x" and "no fix is available" or "update to version X or newer". Then admins can decide for themselves if they want to continue using the plugins. That's how we're doing it at the moment with unresolved security vulnerabilities except in the most egregious cases. If we do this generically enough we can reuse it whenever a similar issue comes up. Then the only thing different is the larger plugin ecosystem we would want to check for compatibility issues, but if that's sufficiently well automated (there'll still be many hundreds of plugins left!), it shouldn't make a huge difference. On the pro side, we don't annoy admins for no real reason because we stop distributing their pet plugin that has worked without problems for years. If we go ahead with this proposal however, implementation-wise, we need to consider the following: How would you handle plugins that are actively maintained but the maintainers don't care about the problems enough to address them? Some plugins are "maintained" by folks happy to merge PRs and create new releases, and that's all they do. What really is the difference between that and having contributors implementing large scale projects get maintainer permission temporarily to merge and release their own PR? And would such a one-off release reset the deprecation clock? How would you deal with plugin dependencies? Deprecation should be transitive while the dependency exists, because you cannot install a dependent plugin without the plugin it depends on being available. jquery-ui was last released in 2011 and role-strategy had a dependency on it for most of 2019, catapulting jquery-ui's popularity. In 2019, would you have suspended distribution of jquery-ui, breaking everyone on recent releases of role-strategy? Or, for an ongoing potential issue: If you install Jenkins today and install suggested plugins, you also install these through dependencies (dates are their latest releases): 2016-03-03T12:08:37.00Z - momentjs 2016-03-03T12:09:31.00Z - ace-editor 2017-01-16T17:29:02.00Z - pipeline-github-lib Dependent plugins are workflow-cps and pipeline-stage-view (selected via workflow-aggregator). I don't think automatically marking the Pipeline plugin suite deprecated, as some recent responses to this thread recommend, helps anyone. -- 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/CAMo7PtLxvcBZuNPwVwEb3PrLk1SAmkS%3DhK9q_fJph5crp%3DuVFg%40mail.gmail.com.
