> I am not sure exactly sure what you mean by this, but I am certainly not requesting nor expecting you to support any fallout of this PR. Our team will obviously step up if something bad arises
Sorry for confusion, I have no doubt that your team will provide good support for this change. What I meant is that I am not ready to put my +1 for merging, but I do not block others from proceeding with the merge. > What I'm trying to avoid here is stalling this work. We created this PR on the 1st of March. I do not want to stall it either. This is a good technical debt reduction work, and " I definitely do not want the PR to miss the LTS merge window" like stated above. I'd love to see it in the September LTS release. We are also interested to get it in weekly rather sooner than later so that we can address any regressions if reported. >> and do the better effort in reaching out to plugin maintainers and getting releases or explicit up-for-adoption where possible. > Care to elaborate please? IIUC you mean sending an email to the last known maintainers for plugins that are going to be broken when we merge the Core PR. Yes, I mean sending emails offering to either merge/release the fix or to put the plugin for adoption. It would be great to finalize Basil's plugin EOL JEP so that we have this process more or less automated. But now yes, emails. They can be retrieved from the plugin metadata, Jira or Git commit history. I can help with these emails as a board member. > TBH after this, I fear a bit the Guava upgrade that we want to help on next... Topic for a contributor summit? I also expect difficulties with Guava upgrade and then Groovy update needed for Java 17 and housekeeping. Contributor summit could be a good venue to develop strategy for such massively used components. > What, specifically, is the threshold of usage that would cause you to express concern? I do not have a specific threshold at the moment. And I do not think the installation numbers represent the community importance well. Big Jenkins setups at enterprises tend to use "exotic" plugins with low installation numbers, just because they have specific requirements to their environment and scalability. Admins of these instances also tend to disable sending usage stats when they discover this option. So I just use personal expertise which might be biased due to my Hardware/Embedded background. Ask Daniel or Jesse how often they do a facepalm after hearing about my use-cases and hacks :) Speaking seriously, we could definitely think about defining our criteria about what we care during such upgrades. Stale plugins and plugins waiting for adoption for years should not be a blocker for changes we need as the community. On Monday, May 31, 2021 at 11:57:12 PM UTC+2 [email protected] wrote: > Dear Oleg, > > On Sun, May 30, 2021 at 11:55 AM Oleg Nenashev <[email protected]> > wrote: > > I have commented about the plugins removal in another thread. > > In particular, you wrote: "From the list, I am particularly concerned > about Code Coverage plugins which seemed to be actively used." > > You expressed concern about Emma, a code coverage plugin with 3,148 > installations. You did not express concern about BlameSubversion, a > plugin not related to code coverage with 825 installations. > > What, specifically, is the threshold of usage that would cause you to > express concern? > > Thanks, > Basil > -- 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/7486685b-b93e-4151-b952-8b927bf7f7d0n%40googlegroups.com.
