Re: Request to (co-)maintain MultiSCM plugin

Some people like being the default assignee. Others prefer it stay unassigned until someone starts working on it. It's your call. Isn't hard to change either On Mon., May 3, 2021, 3:03 p.m. Jim Klimov, wrote: > On May 3, 2021 8:34:49 PM UTC, Oleg Nenashev > wrote: > >Hi Jim, > > > >I have

Re: Request to (co-)maintain MultiSCM plugin

On May 3, 2021 8:34:49 PM UTC, Oleg Nenashev wrote: >Hi Jim, > >I have granted you permissions. Let me know whether you want to be a >default assignee in Jira. >To do the releases, you will need to >update

Re: JEPs & BDFL ~ KK

> > In the case changing "Sponsor" -> "Champion/Owner" and adding "(New role) > Sponsor", I'm not convinced there's a huge win there. We already define a > "Reviewer" role as an alias for "BDFL and BDFL Delegate". If we replace > the "BDFL Delegate" field with "Reivewer" wouldn't that be

Re: JEPs & BDFL ~ KK

As one of the "Sponsors" of JEP-1, I should probably weigh in. I support streamlining the JEP process any way the community sees fit to do. Removing the BDFL and BDFL Delegate, replacing them with the Governance Board certainly makes sense at this point. Howver, I don't like changing the

Re: Native build of Jenkins CLI

> There is discussion in https://issues.jenkins.io/browse/JENKINS-26463 and I actually started a prototype years ago. Some changes made since then make the task a bit easier. I also started a PoC a while ago and then failed. Indeed it should be easier now. Reworking the structure could also

Re: Request to (co-)maintain MultiSCM plugin

Hi Jim, I have granted you permissions. Let me know whether you want to be a default assignee in Jira. To do the releases, you will need to update https://github.com/jenkins-infra/repository-permissions-updater/blob/master/permissions/plugin-multiple-scms.yml Best regards, Oleg On Monday,

Re: CDF Technical Oversight Committee - Jenkins project representative nominations

> Having more motivative contributors is crucial for the community. Sharing your routine or stories to us might be a good way to let those who is interested in the community contribution even leading. If there’s any chances I’d like to take some responsibility. Thanks, it is much appreciated.

Re: Jenkins SDLC Security: LFX Security/Snyk adoption status updates

Thanks for the interest Daniel! >> Would you like to participate as a contributor? > What does this entail? That's a good question, to be seen. As a part of the pilot project we will need: - Try out LFX Security 2.0 and configure it for some of our projects - Explore options for

Re: Jenkins SDLC Security: LFX Security/Snyk adoption status updates

Thanks again for driving this, Oleg! > On 3. May 2021, at 19:14, Oleg Nenashev wrote: > > The proposal is to start the pilot from a small list of the repositories > controlled by the pilot project participants: Jenkins core, its libraries, > and some plugins from maintainers who are

Re: Request to (co-)maintain MultiSCM plugin

+1 from me. Thanks for being willing to adopt the plugin. On Sun, May 2, 2021 at 7:29 PM Jim Klimov wrote: > Hello, > > I'd hereby like to ask to be anointed a maintainer for > https://plugins.jenkins.io/multiple-scms/ to keep it sufficiently in line > with modern Jenkins requirements such as

Re: Plugin end-of-life (EOL) policy

On Mon, May 3, 2021 at 3:46 AM Daniel Beck wrote: > Something more extensible, with version ranges like we do for security > warnings could help here: > "This plugin is likely to break the UI once you update Jenkins to 2.277.x" > and "no fix is available" or "update to version X or newer". >

Re: Request to (co-)maintain MultiSCM plugin

On Sun, May 2, 2021 at 9:29 PM Jim Klimov wrote: > pipelines with several custom-argument checkout steps achieve a similar > effect […] probably being a reason to not develop a pipeline integration > for this plugin Indeed, this plugin is not necessary for Pipeline users. > but for legacy

Re: Native build of Jenkins CLI

On Fri, Apr 30, 2021 at 6:07 PM Oleg Nenashev wrote: > do you have any performance metrics? I did not spend much time doing exacting measurements, but it does start basically instantly, unlike the JAR version. Of course it then needs to contact the Jenkins service, which could be faster or

Re: JEPs & BDFL ~ KK

Hi all, I am not sure this is the last conversation about the JEPs process, but as a JEP Editor I would like to recover it. Currently the JEP process does NOT workm neither for the original inspiration s nor for the documentation purposes. We have multiple JEPs created recently, but they get

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

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

Re: Plugin end-of-life (EOL) policy

On Tue, Apr 27, 2021 at 4:00 AM Basil Crow wrote: > Abandoned plugins cause friction for both Jenkins users and contributors > alike. > > They cause friction for users because they are unlikely to be simpatico > with newer features like Pipeline. In the worst case, they are downright >

Re: war file not available on get.jenkins.io

Just for the context, we need to fix INFRA-2961 before adding archives.jenkins-ci.org to the pool of mirrors on get.jenkins.io On Mon, May 3, 2021, at 8:42 AM, 'Olblak' via Jenkins Developers wrote: > Hi, > > We have a mirror containing a copy

Re: war file not available on get.jenkins.io

Hi, We have a mirror containing a copy of every artifacts created. It's https://archives.jenkins-ci.org and your file is available on https://archives.jenkins-ci.org/war-stable/2.164.2/ We recently had to remove archives.jenkins.io from the get.jenkins.io configuration as we have some work