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 <[email protected]> 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 <[email protected]> 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 <[email protected]> a écrit : >> >>> >>> >>> Le mar. 1 juin 2021 à 08:48, Oleg Nenashev <[email protected]> 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 [email protected] wrote: >>>> >>>>> Dear Oleg, >>>>> >>>>> On Sun, May 30, 2021 at 11:55 AM Oleg Nenashev <[email protected]> >>>>> wrote: >>>>> > I have commented about the plugins removal in another thread. >>>>> >>>>> In particular, you wrote: "From the list, I am particularly concerned >>>>> about Code Coverage plugins which seemed to be actively used." >>>>> >>>>> You expressed concern about Emma, a code coverage plugin with 3,148 >>>>> installations. You did not express concern about BlameSubversion, a >>>>> plugin not related to code coverage with 825 installations. >>>>> >>>>> What, specifically, is the threshold of usage that would cause you to >>>>> express concern? >>>>> >>>>> Thanks, >>>>> Basil >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Jenkins Developers" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/jenkinsci-dev/7486685b-b93e-4151-b952-8b927bf7f7d0n%40googlegroups.com >>>> <https://groups.google.com/d/msgid/jenkinsci-dev/7486685b-b93e-4151-b952-8b927bf7f7d0n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >> 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 >> [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS6uUVLXR2us3FuouA_8URPNNme8RtfRoROuLzaTXRXR6A%40mail.gmail.com >> <https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS6uUVLXR2us3FuouA_8URPNNme8RtfRoROuLzaTXRXR6A%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLDqV3%3DUf6O_oVYskGjGu8bWw263ZZOcO%2B%3DZNg%2BDb%2BMLAA%40mail.gmail.com > <https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLDqV3%3DUf6O_oVYskGjGu8bWw263ZZOcO%2B%3DZNg%2BDb%2BMLAA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS5vOy_ADLsiwG708mFMwaqKMGxQ8CdFYPCX8MoV8xodgA%40mail.gmail.com.
