[Heads-up] Removing commons-digester from Jenkins Core (and the link with our plugins EOL policy discussion :-))

[Baptiste Mathus]

Hi all,

I was considering just posting a link in the plugins EOL thread, but thought I'd fork to keep the other thread focused. (and not end up stealing it).

We are currently working on removing commons-digester:2.1 from Jenkins Core. 

https://github.com/jenkinsci/jenkins/pull/5320

After considering an upgrade, we chose the removal path. In particular because the very reason why it is outdated (2010...) and hard to update is that it leaked since many years in the whole Jenkins ecosystem. So we are doing what is deemed right by many, rather than just upgrading so we're in the same situation in 5+ years from now.

As Jesse put it:

I would rather suggest deprecating Digester2 and maybe detaching it to a split plugin, unless we can kill all plugin references.

After analyzing the impact, we are now pursuing the "unless" part :-). We're fixing the ecosystem instead. 20 plugin PRs, counting.

So this email has a few purposes:

1. Raise awareness on these 20+ PRs we opened to fix the ecosystem. If you are a Jenkins plugin maintainer, please look at the list in the table in the description of the Core PR above.
2. Add an interesting data point to the plugin EOL policy discussion: you'll see that in these PRs, a lot are on *very* old plugins, which many look unmaintained. If the policy was in place already, this may have simplified our work subtantially. And I do think this is vital for us that we can spend our scarce time rather on making Jenkins shine, than on making sure plugins released last 5 to 9 years ago, with less than 200 installs worldwide, still work...
3. Custom plugins: if you have developed a custom in-house plugin in your company, please make sure to NOT use commons-digester anymore from Jenkins Core.

Given Guava update/removal is another (_much_ bigger) subject in the radar, I thought raising this would be a good thing for a global awareness.

Again, I think being able to tackle such cleanup tasks is vital to our continued success. 

Being stuck to use some 10+ years old dependencies in our beloved tool cannot be a good thing.

While we have always valued compatibility deeply, we also accepted that potentially breaking some things is critical for us to be able to focus more of our time on the right things. 

-- Baptiste

[Oleg Nenashev]

Hi Baptiste,

Thanks a lot for this work! Commons Digester is definitely a legacy that we should rather remove from Jenkins. It should be perfectly fine as long as we provide an upgrade path in plugins, timely deprecate and announce the removal. We're doing pretty much the same process for Ruby and Python plugin runtimes, and the process can be partially inherited from that or, if you prefer a longer rollout, from JEP-200.

If we have many such removals, slated for a single release, maybe we should consider doing Jenkins 3. I have a proposal in works towards the contributor summit in June, but I am not ready to share it yet.

Best regards,

Oleg Nenashev

P.S: +100 for referencing Shifting Gears!

[Baptiste Mathus]

Hi all, so our team landed all 23 PRs needed to adapt the identified impacted plugins in the ecosystem.

The thing is: in those PRs, many plugins are just abandoned, some since up to 9 years.

The detailed status table is available on the PR itself: https://github.com/jenkinsci/jenkins/pull/5320

I have just done another round of status assessment on the whole list.

In summary the status is the following:

• subversion, maven-info and clover: Done. They got a release already. (thanks Tim, Marek & Olivier!) 
• cvs fix is merged, waiting for a release. (this is really the only must-have to me, cvs still being reported as installed 40k times...)

These 4 above are the most installed plugins impacted by the removal of commons-digester. 

The least popular of these 4 is clover with 3521 installs.

In short, here are the plugins that I do not think we will get a merge, even less a release for, because of lack of maintainership:

• emma 3216
• cloverphp 2801
• vs-code-metrics 1435
• BlameSubversion 878
• javatest-report 440
• clearcase-ucm 266
• vss 168
• synergy 96
• config-rotator 62
• harvest 49
• cmvc 18

So the big question is: what do we do?

I personally think we should NOT make these PRs land if no maintainer steps up. 

In other words, once we merge and release the Core PR, these plugins will likely just fail loading on newer Jenkins releases.

I'm proposing the following action plan to move forward:

• This week: blog entry on Jenkins.io summarizing this and heads-up to users for these plugins 
• Some time next week: merge https://github.com/jenkinsci/jenkins/pull/5320
• this way we still give some more time to plugins to be released (like cvs). 
• 2021-05-17: the first weekly without commons-digester:2.1 is released.
• anything else?

(I'm also thinking we might want to consider using an AdminMonitor, like the PluginDeprecationMonitor?, not sure anymore what we'd do nowadays for such case?)

WDYT?

--
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-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/ea8584a7-12ce-42a4-b89c-6b95b91461f6n%40googlegroups.com.

[Jesse Glick]

On Tue, May 4, 2021 at 5:02 PM Baptiste Mathus <m...@batmat.net> wrote:

• cvs still being reported as installed 40k times...

Of course most of those installations are unused; it is a detached plugin.

[Basil Crow]

On Tue, May 4, 2021 at 2:02 PM Baptiste Mathus <m...@batmat.net> wrote:
> So the big question is: what do we do?
>
> I personally think we should NOT make these PRs land if no maintainer steps up.
> In other words, once we merge and release the Core PR, these plugins will likely just fail loading on newer Jenkins releases.

I concur with Baptiste. For plugins that have not seen any activity,
yet alone a release, in more than five years (and on which no other
plugins depend), I do not believe the benefit to be gained is worth
the cost.

[Oleg Nenashev]

What about a quick JEP? We are working on removing obstacles in the process, an a test for the new process would be great

--
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/m2fEX5ALvbg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjp9q5sdO%2BuYUH2voGYqufHs%2BE3gULdvdnwCHwgWGByLEg%40mail.gmail.com.

[Manuel Ramón León Jiménez]

I'm against a JEP for Digester removal. It doesn't need it IMO. I'm in for anything to avoid us dealing with the same problems in the future. We need to modernize Jenkins in many aspects and those old / unmaintained plugins are an obstacle and a waste of effort. Something like put for adoption every plugin without a release for a year or use another label and state clearly that the effort from the community won't take into account the plugins with this label. Or something like that.

Basically what Oleg wrote on the email Plugin end-of-life (EOL) policy.

Thanks!

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-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLDz5m2Z8W441jCPQAxsj%3DvfG2uK5TdRJZpLXSH8uanKfA%40mail.gmail.com.

[Daniel Beck]

> On 5. May 2021, at 09:41, Manuel Ramón León Jiménez <manuelramon...@gmail.com> wrote:
>
> I'm against a JEP for Digester removal. It doesn't need it IMO. I'm in for anything to avoid us dealing with the same problems in the future. We need to modernize Jenkins in many aspects and those old / unmaintained plugins are an obstacle and a waste of effort.

Time to delete https://www.jenkins.io/project/governance/#compatibility-matters then, because looking at this thread, compatibility clearly doesn't matter anymore?

[Liam Newman]

Daniel, 

From that link: 

This is not to say we don’t ever remove anything, but we do it very carefully.

We are being careful.  I think creating a JEP, even a mostly retrospective one, is worth doing.  If nothing else we should do so because of concerns like those voiced by Daniel. I will take that task on myself if needed. 

  -L. 

 

--
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-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/B214EACA-57A8-4EB4-9FFA-C59B2F0D9D89%40beckweb.net.

[Baptiste Mathus]

Exactly what Liam said. 

I did call out this very page about "compatibility matters" on my first mail in this thread.

I think we are being extremely careful. We even filed PRs on plugins that the Jenkins Project does not serve anymore and/or plugins abandoned since close to 10 years.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAA0qCNwD%3DMMh5i%2BjeEte6CxRqQ%3DcCVEZqmNMxtPcgC8JUJ_0vA%40mail.gmail.com.

[Jesse Glick]

On Tue, May 4, 2021 at 10:58 PM Oleg Nenashev <o.v.ne...@gmail.com> wrote:

What about a quick JEP?

The rule of thumb is that if you are not sure if a JEP might be needed…file a JEP. It is how we document any decision that might be controversial or require explanation or context. Certainly any deliberate compatibility break falls into this category. If your arguments for why we should do something are coherent, it should not take long to write up a few paragraphs in AsciiDoc and file it.

[Baptiste Mathus]

Agreed. We'll do one

[Oleg Nenashev]

Hi all. Please do not consider JEP as a huge overhead. As discussed in another thread, we will be working on simplifying the process for contributors. The process is not meant to be an obstacle, and I plan to keep simplifying it where possible.

And, to everyone, please be kind. All of us share the goal to improve Jenkins and reduce maintenance overheads

[Liam Newman]

Here's the PR submitting JEP for Digester Removal:  https://github.com/jenkinsci/jep/pull/361 

--

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-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/f8066f0c-9dfe-4209-8fe8-e19bcf30b8e7n%40googlegroups.com.

[Baptiste Mathus]

Hi everyone, 

Update on this subject:

The JEP has been created and given the JEP-231 number https://github.com/jenkinsci/jep/tree/master/jep/231

• (We will update the table listing impacted plugins in the JEP soon with the correct latest status -- latest status, checked a few minutes ago is in the PR itself for now)
  

What will happen when we merge the Core PR https://github.com/jenkinsci/jenkins/pull/5320?

=> starting with the following weekly, the following plugins would not work anymore:

emma, cloverphp, vs-code-metrics, BlameSubversion, javatest-report, vss, genexus, synergy, config-rotator, harvest, cmvc 

(for perspective, the emma plugin is the most installed with 3.2k installs, and then it drops quickly.)

Note that we have filed a PR to fix this issue for *all* these plugins. So if anybody was to step up in the future, they could easily take ownership, merge & release the corresponding plugin.

Basil has been nice enough to prepare a PR to show users that these plugins are deprecated:

https://github.com/jenkins-infra/update-center2/pull/525

Hence, I think this is time for us to move forward. I think we have taken the due care needed to respect our "compatibility matters" stance. 

And given we know exactly the impact, it is reasonable to move on.

I would like to formally request we merge this PR.

If not, I'm ready to consider additional actions, but then I'd like to know which ones :).

What I'm already having in the radar:

* send a heads-up to the users ML

* write a blog entry about this subject

Anything else?

Thank you!

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAA0qCNyOnh-O1o%2Bo2srtHd38G%3DQbpYA6mDS2Wt6T8M0f4ahJqw%40mail.gmail.com.

[Basil Crow]

+1 from me

[Matt Sicker]

+1 thanks for doing your due diligence!

On Fri, May 28, 2021 at 19:14 Basil Crow <m...@basilcrow.com> wrote:

+1 from me

--
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-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjrQBdo645Zs5cboXStgo_7zJEEsnQ3iCxQ6qC4iw4M%3D4g%40mail.gmail.com.

[Oleg Nenashev]

Hi all,

I have commented about the plugins removal in another thread. I have a question about creating a detached plugin for commons-digester: " The current plan causes plugins which depend on Jenkins to provide Digester to fail unless they are updated. This could be mitigated by moving this dependency to a detached plugin. We decided against creating a detached pluging because there were a small number of affected plugins and only a few of them have significant install base. The creating and maintaining of a detached plugin would still be a significant amount of work and would cause the security vulnerabilities we are trying to address to remain open"

I agree with the reasoning and the decision. At the same time time it does not explain why the commons-digester3 library is being injected as a direct dependency in pull requests, e.g. https://github.com/jenkinsci/vs-code-metrics-plugin/pull/5/ . Would it make sense to create a new API plugin instead? Otherwise we risk running into compatibility concerns at some point. Creating an API plugin is not discussed in the JEP at all.

Best regards,

Oleg Nenashev

P.S: Sorry for being a bit late to comment

[Baptiste Mathus]

Le dim. 30 mai 2021 à 20:55, Oleg Nenashev <o.v.ne...@gmail.com> a écrit :

Hi all,

I have commented about the plugins removal in another thread. I have a question about creating a detached plugin for commons-digester: " The current plan causes plugins which depend on Jenkins to provide Digester to fail unless they are updated. This could be mitigated by moving this dependency to a detached plugin. We decided against creating a detached pluging because there were a small number of affected plugins and only a few of them have significant install base. The creating and maintaining of a detached plugin would still be a significant amount of work and would cause the security vulnerabilities we are trying to address to remain open"

I agree with the reasoning and the decision. At the same time time it does not explain why the commons-digester3 library is being injected as a direct dependency in pull requests, e.g. https://github.com/jenkinsci/vs-code-metrics-plugin/pull/5/ . Would it make sense to create a new API plugin instead? Otherwise we risk running into compatibility concerns at some point. Creating an API plugin is not discussed in the JEP at all.

Right. We could create a digester3-api plugin. 

Indeed, to follow your point: currently, plugins were theoritically (in practice never, given digester2 is loooong deprecated) getting this centralized at Jenkins Core level.

It was kinda like these plugins were using an api-plugin.

Now for adjusted plugins, each one would have to upgrade separately when/if a new release is made for digester3.

Just to make sure I get your point/stance:

* you would agree we mark the current PR as ready-for-merge 

* [provided we enrich the JEP-231 with the following [?]]

* to make things better for the future, you recommend we create a digester3-api plugin so these plugins can all be updated in one go.

I think I like this idea. This whole Digester2 work is about cleaning up some burden of Jenkins, and such an API plugin would avoid having to manually update dozens of plugins if a vulnerability fix was to be released on the digester3 line.

We can definitely and happily commit to create such an API plugin and adapt active plugins if that is the last blocker us to move forward and merge this PR in the Core :-).

Are we missing anything else to allow this merge?

What do you think Oleg? What do you all think?

Best regards,

Oleg Nenashev

P.S: Sorry for being a bit late to comment

On Saturday, May 29, 2021 at 2:41:26 AM UTC+2 boa...@gmail.com wrote:

+1 thanks for doing your due diligence!

On Fri, May 28, 2021 at 19:14 Basil Crow <m...@basilcrow.com> wrote:

+1 from me

--
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-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjrQBdo645Zs5cboXStgo_7zJEEsnQ3iCxQ6qC4iw4M%3D4g%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-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/4b2291aa-2a87-4d62-992b-c944b1c19aa4n%40googlegroups.com.

[Oleg Nenashev]

> Just to make sure I get your point/stance:

> * you would agree we mark the current PR as ready-for-merge 

> * [provided we enrich the JEP-231 with the following [?]]

> * to make things better for the future, you recommend we create a digester3-api plugin so these plugins can all be updated in one go.

Taking two votes here and many approvals in https://github.com/jenkinsci/jenkins/pull/5320, I am not against that. I would prefer us to rather follow the new JEP-1 process draft in https://github.com/jenkinsci/jep/pull/359 so that we could verify and dry run the changes, but I do not want to do modifications for them.

I am not ready to support the PR on my own though, because we should firstly release the API plugin and do the better effort in reaching out to plugin maintainers and getting releases or explicit up-for-adoption where possible. If other core maintainers do not want to wait, I am ready to accept this decision. And I definitely do not want the PR to miss the LTS merge window.

[James Nord]

I am against a digester API plugin as it is not really something that should be used and by making a plugin-api we make that somewhat offical.  We took a quicker path of bumping the digester usage to support 3 than remove / replace it entirely.  as there are only a few plugins using this I think inlining the jar is perfectly fine, infact creating an API for libraries where API compatibility is not guaranteed can make things worse for the future.

/James

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/6d186d75-1d7d-4f05-b874-ef74941828cdn%40googlegroups.com.

[Baptiste Mathus]

Le lun. 31 mai 2021 à 17:41, Oleg Nenashev <o.v.ne...@gmail.com> a écrit :

> Just to make sure I get your point/stance:

> * you would agree we mark the current PR as ready-for-merge 

> * [provided we enrich the JEP-231 with the following [?]]

> * to make things better for the future, you recommend we create a digester3-api plugin so these plugins can all be updated in one go.

Taking two votes here and many approvals in https://github.com/jenkinsci/jenkins/pull/5320, I am not against that. I would prefer us to rather follow the new JEP-1 process draft in https://github.com/jenkinsci/jep/pull/359 so that we could verify and dry run the changes, but I do not want to do modifications for them.

I am not ready to support the PR on my own though,

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.

 

because we should firstly release the API plugin

While, again, I am totally OK to create such a plugin and I'll happily make it happen this week or so, I disagree with the need to absolutely release an API plugin before we merge the Core PR. Given the important plugins are already fixed and released, currently this is more of a maintenance & technical debt issue.

Functionally, users will see no difference.

What I'm trying to avoid here is stalling this work.

We created this PR on the 1st of March. 

The most recent PR to fix even the CMVC plugin (18 installs worldwide) is soon 30 days old.

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.

Reading your email on the users list, if you'd like us to step up and at least temporarily adopt cloverphp & emma to release them, we can do this. 

I'll even start the discussion now.

If other core maintainers do not want to wait, I am ready to accept this decision. And I definitely do not want the PR to miss the LTS merge window.

Thank you. 

Yes, it would certainly be bad for Jenkins future too that it takes us so long to remove anything :-(. 

TBH after this, I fear a bit the Guava upgrade that we want to help on next...

 

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/6d186d75-1d7d-4f05-b874-ef74941828cdn%40googlegroups.com.

[Basil Crow]

Dear Oleg,

On Sun, May 30, 2021 at 11:55 AM Oleg Nenashev <o.v.ne...@gmail.com> 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

[Oleg Nenashev]

> 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.

[Baptiste Mathus]

Le mar. 1 juin 2021 à 08:48, Oleg Nenashev <o.v.ne...@gmail.com> a écrit :

> 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.

OK, I'll do it. I don't plan to wait for their answers though TBH.

I'd like to declare the Digester PR ready-for-merge given the existing approvals.

For all still unreleased plugins:

* For teamconcert, seems there's an active maintainer looking into it.

* Then genexus was active last year around early 2020. So I think we could hope for some answer.

* Then the next unreleased one is config-rotator, last active 4 years ago. Then next is 6 years ago. Not holding my breath for these :-).

> 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.

Good idea. I'll raise it with the team.

> 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.

I like and support this idea.

I don't think however we should block the Digester work until it's done. This is something I'd like to help deliver for the next weeks & months so we can use it for Guava.

 

On Monday, May 31, 2021 at 11:57:12 PM UTC+2 m...@basilcrow.com wrote:

Dear Oleg,

On Sun, May 30, 2021 at 11:55 AM Oleg Nenashev <o.v.ne...@gmail.com> 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 jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/7486685b-b93e-4151-b952-8b927bf7f7d0n%40googlegroups.com.

[Baptiste Mathus]

Email thread pinging last maintainers' emails taken from git log just sent, see the other thread.

[Oleg Nenashev]

Thanks a lot!

> Then next is 6 years ago. Not holding my breath for these :-).

Me neither. We need Basil's plugin EOL work to land

> I'd like to declare the Digester PR ready-for-merge given the existing approvals.

Fine with me. The weekly release is out, so it gives maintainers (if any) one extra week to react until next Tuesday. Should be ok. I will initiate the contdown

> I don't think however we should block the Digester work until it's done. This is something I'd like to help deliver for the next weeks & months so we can use it for Guava.

Yes, I agree with not blocking any pending efforts.

Best regards,

Oleg

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/m2fEX5ALvbg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS6uUVLXR2us3FuouA_8URPNNme8RtfRoROuLzaTXRXR6A%40mail.gmail.com.

[Baptiste Mathus]

FYI all. 

The Core PR got merged.

Blog entry PR up for review https://github.com/jenkins-infra/jenkins.io/pull/4395

I think we should land this blog article asap, so people can start seeing this today to prepare for upcoming weekly.

-- Baptiste

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLDqV3%3DUf6O_oVYskGjGu8bWw263ZZOcO%2B%3DZNg%2BDb%2BMLAA%40mail.gmail.com.