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

[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

Le mer. 2 juin 2021 à 01:00, Oleg Nenashev  a
écrit :

> 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
>
> On Wed, Jun 2, 2021 at 12:47 AM Baptiste Mathus  wrote:
>
>> Email thread pinging last maintainers' emails taken from git log just
>> sent, see the other thread.
>>
>> Le mer. 2 juin 2021 à 00:05, Baptiste Mathus  a écrit :
>>
>>>
>>>
>>> Le mar. 1 juin 2021 à 08:48, Oleg Nenashev  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.
>>> 

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

[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

On Wed, Jun 2, 2021 at 12:47 AM Baptiste Mathus  wrote:

> Email thread pinging last maintainers' emails taken from git log just
> sent, see the other thread.
>
> Le mer. 2 juin 2021 à 00:05, Baptiste Mathus  a écrit :
>
>>
>>
>> Le mar. 1 juin 2021 à 08:48, Oleg Nenashev  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 
 wrote:
 > I have commented about the plugins removal in another thread.

 In particular, you wrote: "From the list, I am particularly concerned

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

[Baptiste Mathus]

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

Le mer. 2 juin 2021 à 00:05, Baptiste Mathus  a écrit :

>
>
> Le mar. 1 juin 2021 à 08:48, Oleg Nenashev  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 
>>> 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-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> 

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

[Baptiste Mathus]

Le mar. 1 juin 2021 à 08:48, Oleg Nenashev  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 
>> 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-dev+unsubscr...@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
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from 

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

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


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  
> 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-dev+unsubscr...@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.

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

[Basil Crow]

Dear Oleg,

On Sun, May 30, 2021 at 11:55 AM Oleg Nenashev  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-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjo8zzYA%3D7MD%3D0jsd3fRJXVRguCTpHW6kK0e%2BVqFXcYN4A%40mail.gmail.com.

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

[Baptiste Mathus]

Le lun. 31 mai 2021 à 17:41, Oleg Nenashev  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...



>
>
>
>
>
>
>
>
>
>
>
> On Sunday, May 30, 2021 at 11:19:25 PM UTC+2 Baptiste Mathus wrote:
>
>> Le dim. 30 mai 2021 à 20:55, Oleg Nenashev  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 lng 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 

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

[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

On Mon, 31 May 2021 at 16:41, Oleg Nenashev  wrote:

> > 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.
>
>
>
>
>
>
>
>
>
>
>
> On Sunday, May 30, 2021 at 11:19:25 PM UTC+2 Baptiste Mathus wrote:
>
>> Le dim. 30 mai 2021 à 20:55, Oleg Nenashev  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 lng 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  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 

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

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











On Sunday, May 30, 2021 at 11:19:25 PM UTC+2 Baptiste Mathus wrote:

> Le dim. 30 mai 2021 à 20:55, Oleg Nenashev  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 lng 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  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
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe 

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

[Baptiste Mathus]

Le dim. 30 mai 2021 à 20:55, Oleg Nenashev  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 lng 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  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-dev+unsubscr...@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
> 
> .
>

-- 
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/CANWgJS4L1utmL3r9zG0_VSmD5SqM-QRv9GdyYLXaVcjTi3rjZg%40mail.gmail.com.

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

[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

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  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-dev+unsubscr...@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.

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

[Basil Crow]

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

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

[Liam Newman]

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

On Wed, May 5, 2021 at 10:37 AM Oleg Nenashev 
wrote:

> 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
>
> On Wednesday, May 5, 2021 at 7:13:42 PM UTC+2 Baptiste Mathus wrote:
>
>>
>> Le mer. 5 mai 2021 à 19:08, Jesse Glick  a écrit :
>>
>>> On Tue, May 4, 2021 at 10:58 PM Oleg Nenashev 
>>> 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.
>>>
>>
>> Agreed. We'll do one
>>
>>
>> --
> 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/f8066f0c-9dfe-4209-8fe8-e19bcf30b8e7n%40googlegroups.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/CAA0qCNyOnh-O1o%2Bo2srtHd38G%3DQbpYA6mDS2Wt6T8M0f4ahJqw%40mail.gmail.com.

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

[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

On Wednesday, May 5, 2021 at 7:13:42 PM UTC+2 Baptiste Mathus wrote:

>
> Le mer. 5 mai 2021 à 19:08, Jesse Glick  a écrit :
>
>> On Tue, May 4, 2021 at 10:58 PM Oleg Nenashev  
>> 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.
>>
>
> Agreed. We'll do one
>
>
>

-- 
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/f8066f0c-9dfe-4209-8fe8-e19bcf30b8e7n%40googlegroups.com.

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

[Baptiste Mathus]

Le mer. 5 mai 2021 à 19:08, Jesse Glick  a écrit :

> On Tue, May 4, 2021 at 10:58 PM Oleg Nenashev 
> 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.
>

Agreed. We'll do one

-- 
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/CANWgJS4gSYUdpZAo%3Dxgp8U8nhj9YzEoMJM85A3b4LAWqaMU%3Dqg%40mail.gmail.com.

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

[Jesse Glick]

On Tue, May 4, 2021 at 10:58 PM Oleg Nenashev 
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.

-- 
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/CANfRfr3r_MNTYM6qJjAAdFQE%3D_EoLwfP7r93_cgVBppn2ta0jQ%40mail.gmail.com.

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

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

Le mer. 5 mai 2021 à 17:28, Liam Newman  a écrit :

> 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.
>
>
> On Wed, May 5, 2021 at 5:14 AM Daniel Beck  wrote:
>
>>
>>
>> > On 5. May 2021, at 09:41, Manuel Ramón León Jiménez <
>> manuelramonleonjime...@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?
>>
>> --
>> 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/B214EACA-57A8-4EB4-9FFA-C59B2F0D9D89%40beckweb.net
>> .
>>
> --
> 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/CAA0qCNwD%3DMMh5i%2BjeEte6CxRqQ%3DcCVEZqmNMxtPcgC8JUJ_0vA%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/CANWgJS6rpBamE_3%3DVGbFjKepLW%3DrdWbkCazF6Jhm5KGo1f2f5g%40mail.gmail.com.

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

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


On Wed, May 5, 2021 at 5:14 AM Daniel Beck  wrote:

>
>
> > On 5. May 2021, at 09:41, Manuel Ramón León Jiménez <
> manuelramonleonjime...@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?
>
> --
> 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/B214EACA-57A8-4EB4-9FFA-C59B2F0D9D89%40beckweb.net
> .
>

-- 
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/CAA0qCNwD%3DMMh5i%2BjeEte6CxRqQ%3DcCVEZqmNMxtPcgC8JUJ_0vA%40mail.gmail.com.

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

[Daniel Beck]

> On 5. May 2021, at 09:41, Manuel Ramón León Jiménez 
>  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?

-- 
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/B214EACA-57A8-4EB4-9FFA-C59B2F0D9D89%40beckweb.net.

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

[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!

On Wed, May 5, 2021 at 4:58 AM Oleg Nenashev  wrote:

> What about a quick JEP? We are working on removing obstacles in the
> process, an a test for the new process would be great
>
> On Wed, May 5, 2021, 01:16 Basil Crow  wrote:
>
>> On Tue, May 4, 2021 at 2:02 PM Baptiste Mathus  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.
>>
>> --
>> 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-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjp9q5sdO%2BuYUH2voGYqufHs%2BE3gULdvdnwCHwgWGByLEg%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/CAPfivLDz5m2Z8W441jCPQAxsj%3DvfG2uK5TdRJZpLXSH8uanKfA%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/CADN1OJ1%3DpCdSQrQiqM%2BxVgOczh0n9MoyiV3HcPGQkc3r%3D0k8gg%40mail.gmail.com.

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

[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

On Wed, May 5, 2021, 01:16 Basil Crow  wrote:

> On Tue, May 4, 2021 at 2:02 PM Baptiste Mathus  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.
>
> --
> 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-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjp9q5sdO%2BuYUH2voGYqufHs%2BE3gULdvdnwCHwgWGByLEg%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/CAPfivLDz5m2Z8W441jCPQAxsj%3DvfG2uK5TdRJZpLXSH8uanKfA%40mail.gmail.com.

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

[Basil Crow]

On Tue, May 4, 2021 at 2:02 PM Baptiste Mathus  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.

-- 
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/CAFwNDjp9q5sdO%2BuYUH2voGYqufHs%2BE3gULdvdnwCHwgWGByLEg%40mail.gmail.com.

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

[Jesse Glick]

On Tue, May 4, 2021 at 5:02 PM Baptiste Mathus  wrote:

>
>- cvs still being reported as installed 40k times...
>
>
Of course most of those installations are unused; it is a detached plugin.

-- 
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/CANfRfr31JN9xXgmarq%2Bo7N6Z-njEZ4LoDcgKjZZb8MravuR1Yg%40mail.gmail.com.

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

[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?


Le lun. 3 mai 2021 à 10:33, Oleg Nenashev  a écrit :

> 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!
>
>
> On Sunday, May 2, 2021 at 10:52:26 PM UTC+2 Baptiste Mathus wrote:
>
>> 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 

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

[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!


On Sunday, May 2, 2021 at 10:52:26 PM UTC+2 Baptiste Mathus wrote:

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

-- 
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/ea8584a7-12ce-42a4-b89c-6b95b91461f6n%40googlegroups.com.

[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

-- 
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/CANWgJS5YdwNL_CExjed%2B4R-jcDyai-BPPRhR-PkNvZRm%3Dk4u%3Dw%40mail.gmail.com.