Re: [jenkinsci-board] Proposal: Jenkins funding page on LFX Crowdfunding

Thanks to Ulli for the feedback and for offering help! Restored the dev list in CC. Seems that the bureaucracy is starting to increase in several areas of > Jenkins now, but maybe this is a very subjective view. (But I am not a fan > of creating a new complex process here.) > Any suggestions on

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

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

Re: [Digester] Adopt plugins emma & cloverphp

PR https://github.com/jenkins-infra/repository-permissions-updater/pull/1975 Le lun. 31 mai 2021 à 23:10, Baptiste Mathus a écrit : > In CC, > Seiji Sogabe & patrick-brueckner for cloverphp... > brandt & Manolo Carrasco for emma. > > Hi all, I'd like to adopt these two plugins to be able to

Re: [jenkins-infra] Elastic Sponsorship for OpenTelemetry usage for community Jenkins instances

Can you elaborate what information you want to gather? What build metrics and traces? > Am 31.05.2021 um 11:47 schrieb Damien Duportal : > > Good point Oleg, thanks a lot for this reminder! > > Any test on infra.ci.jenkins.io must be done on > a private APM

[Digester] Adopt plugins emma & cloverphp

In CC, Seiji Sogabe & patrick-brueckner for cloverphp... brandt & Manolo Carrasco for emma. Hi all, I'd like to adopt these two plugins to be able to release them with the adaptation for Digester. For perspective, both plugins' last activity & last release were in 2015: -

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

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

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

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

I would like to become committer/maintainer on a plugin

Hello, I would like to become a committer or even maintainer on the Calendar View Plugin: https://plugins.jenkins.io/calendar-view/ I want to merge at least the following Pull Requests: - https://github.com/jenkinsci/calendar-view-plugin/pull/21 -

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

> 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

SCM API, how to add traits to old job configurations

Hi there, I have a question regarding SCMNavigatorDescriptor. I would like to implement a newer version of the plugin where the current behaviour of the SCMNavigator is deported and divided into multiple Traits for configuration. The issue is that I would like to maintain a working state for the

Re: [jenkinsci-board] Re: Proposal: Jenkins funding page on LFX Crowdfunding

Thanks to Gavin for bringing up the over-commitment concern. I can totally relate to that, and I would not like to take the role just to do treasury management single handedly. FTR the role of the treasurer includes multiple parts: - monitoring and reporting on budgets. This assignment can be

Re: [jenkins-infra] Elastic Sponsorship for OpenTelemetry usage for community Jenkins instances

Good point Oleg, thanks a lot for this reminder! Any test on infra.ci.jenkins.io must be done on a private APM instance, to ensure no sensitive data is leaked. It means that we should only do it for testing purpose, and the feedback to the community will need a

ci.jenkins.io configuration as code

[Cross-posted on jenkins-infra and jenkins-dev] Hello dear users of ci.jenkins.io , As part of the public roadmap (https://www.jenkins.io/project/roadmap/ , filter on "Infrastructure and Services"), one of the task that we (the