Re: Release team members

Good initiative Tim, thank you :) (yes you can add me ^^) Wadeck On Friday, September 24, 2021 at 9:52:30 AM UTC+2 Ildefonso Montero wrote: > No issues from my side :-) Thanks for driving this Tim! > > On Thu, Sep 23, 2021 at 9:29 PM Mark Waite wrote: > >> I would like to be a member of that

Re: Backporting for LTS 2.319.3 started

Please Ilde, also include https://issues.jenkins.io/browse/JENKINS-67702 to prevent scanners to complain about XStream On Monday, January 31, 2022 at 9:56:23 AM UTC+1 Vincent Latombe wrote: > +1 from me to backport it. > > Vincent > > > Le lun. 31 janv. 2022 à 09:43, 'Ildefonso Montero' via Jenk

Re: File Leak Detector

+1 On Tuesday, March 1, 2022 at 1:02:21 PM UTC+1 manuel.ramon...@gmail.com wrote: > +1 > > On Tue, Mar 1, 2022 at 12:28 PM Oleg Nenashev wrote: > >> +1 >> >> >> On Tuesday, March 1, 2022 at 8:36:47 AM UTC+1 timja...@gmail.com wrote: >> >>> +1 >>> >>> On Tue, 1 Mar 2022 at 01:26, Mark Waite wro

Re: Correct permission checks to add

Hello, Superficial read => I imagine you should use Item.CONFIGURE and not the generic Permission.CONFIGURE. Wadeck On Thursday, April 28, 2022 at 1:12:47 AM UTC+2 tim.va...@gmail.com wrote: > Hi, > > I added the Jenkins security scan to my plugin on GitHub and resolved all > the issues.Or,

Re: Backporting for LTS 2.346.1 started

Hey there, especially Alex, Usually we have a two weeks period for the RC, once the backports are merged. In this case, we have a PR that is still pending, ~one week after the expected delay. PR in question: https://github.com/jenkinsci/jenkins/pull/6618 So, two questions: 1) Is it OK if we are

Re: Backporting for LTS 2.346.1 started

Hey there, especially Tim, The next question related to the extra week delay, what do you expect to do for the .2 LTS release? It seems that currently it's still scheduled in 3 weeks. Wadeck On Tuesday, June 7, 2022 at 11:05:49 PM UTC+2 timja...@gmail.com wrote: > Fine to delay the extra we

Security approval required on UI-related PRs in Jenkins core

Today the Jenkins project released a security version that contains several high severity vulnerabilities. Five vulnerabilities from Jenkins core were introduced very recently during UI improvement work. Such security issues discovered af

Re: Security approval required on UI-related PRs in Jenkins core

ld be >> looked at ASAP then that would be great. >> >> Let’s add this as an agenda item for the next UX sig meeting to review >> how it’s going >> >> Thanks >> Tim >> >> On Wed, 22 Jun 2022 at 18:37, 'wfoll...@cloudbees.com' via Jenkins

Re: Security approval required on UI-related PRs in Jenkins core

at 9:30:47 PM UTC+2 db...@cloudbees.com wrote: > On Wed, Jun 22, 2022 at 9:26 PM 'wfoll...@cloudbees.com' via Jenkins > Developers wrote: > >> Great idea Alex => *@jenkinsci/core-security-review* created >> >> Thanks for the feedback and yes Tim, I will

Re: GSoC Project - Plugin Health Score Survey for Maintainers

Hello Dheeraj, Are you able to share the data distribution for the individual probes you already have in place? This will greatly help us understanding what should be done with the rules. E.g. if all plugins have a code coverage of 50%+, the weight should take that into consideration, in oppos

Re: Proposal: Alexander Brandes (@NotMyFault) to join the Core team

+1, thanks Alex for the several contributions you did over the recent period. Looking forward for the next period ;) On Thursday, October 13, 2022 at 3:12:04 PM UTC+2 Kevin Martens wrote: > +1 from me too! > > On Thu, Oct 13, 2022 at 5:52 AM 'Olblak' via Jenkins Developers < > jenkin...@googlegr

Re: Next LTS baseline selection

FTR 2.375 was released ~4h ago, the changelog page is not even updated (to receive the feedback). With the list of regression/bug fix it seems to be a good candidate, but I think we should monitor carefully the user feedbacks and be ready to provide backports to a previous version. To ease this

Re: End of year holidays and Jenkins 2.375.2 release schedule

For the delay of the LTS realease, with pleasure! :-) For the RC, no opinion. On Tuesday, November 22, 2022 at 3:53:47 PM UTC+1 Mark Waite wrote: > In the past few years, we've taken a break from our regular LTS schedule > over the holiday season. I propose we take a break this year, though w

Re: Proposal to ensure new plugin hosting requests use Maven instead of Gradle

+1 On Thursday, December 8, 2022 at 8:27:13 AM UTC-8 Adrien Lecharpentier wrote: > +1 as well from me. > > Le jeu. 8 déc. 2022 à 17:19, Damien Duportal a > écrit : > >> +1 >> >> Le mercredi 7 décembre 2022 à 15:49:42 UTC+1, bma...@gmail.com a écrit : >> >>> +1. >>> >>> At least such a move wil

Re: JDK19 is now available on ci.jenkins.io

+1 for the edge approach, to not create "superficial" tech debt On Thursday, December 8, 2022 at 8:34:12 AM UTC-8 slide wrote: > I think the edge idea is a good one. This reduces the churn on Jenkinsfile > changes to support building on the latest. It would be nice if we, as > plugin developer

Re: Revert of breadcrumb bar accessibility change

Thanks Basil for the message (I especially liked the references). I can only +1 your proposal as I was thinking about that in https://github.com/jenkinsci/jenkins/pull/6912#issuecomment-1331141923. Compared to you, I didn't take the time to move the idea further, thanks for the effort. The cha

Re: Removing inactive Core maintainers to reduce risk

ositories secure! > > > Was this decision made in concert with other core maintainers > > I was not aware of such a change, but I heavily endorse the cleanup :) > > Alex > > On Friday, 27 January 2023 at 16:59:41 UTC+1 m...@basilcrow.com wrote: > >> On Fri, Jan 27,

Re: Removing inactive Core maintainers to reduce risk

ntent. > [...] I think it should’ve been discussed on the mailing list publicly For the CERT list, I will post a message in the mailing list before removing the inactive users. On Sunday, January 29, 2023 at 8:53:27 PM UTC+1 m...@basilcrow.com wrote: > On Sun, Jan 29, 2023 at 4:52 AM 

Re: Removing inactive Core maintainers to reduce risk

> [...] jenkinsci/inactive-core-maintainers [...] +1 for the idea And thanks for providing additional rationales behind the approach. For Basil: As it's about reducing the risk and not eliminating it, the approach was voluntarily not aggressive. If you want to have a stricter / more aggressive a

Hosting request - Update on the security audit part

Hello there, To give you a bit of context, let me give you my definition of the return on investment (ROI) for the security team. I consider the investment mainly as time and task difficulty. For the value, it's mainly the number of users receiving a more secure application. Directly from this

Re: Requesting Admin access to the jenkinsci organization

+1 Thanks Alex for your continued effort in the project :-) On Monday, June 5, 2023 at 1:15:42 PM UTC+2 timja...@gmail.com wrote: > +1 > > On Mon, 5 Jun 2023 at 10:05, Ullrich Hafner wrote: > >> +1 from me >> >> Am 05.06.2023 um 09:50 schrieb Alexander Brandes : >> >> Hey everyone, >> >> I wou

Re: Requesting admin access to the jenkinsci GitHub organization

+1 On Tuesday, June 6, 2023 at 10:36:39 AM UTC+2 Adrien Lecharpentier wrote: > +1 as well from me. > > Le mar. 6 juin 2023, 10:15, Baptiste Mathus a écrit : > >> +1. >> >> Le lun. 5 juin 2023 à 19:33, Srikanth Jana a >> écrit : >> >>> +1 from me >>> >>> On Mon, Jun 5, 2023 at 11:01 PM Alexande

Removing inactive CERT members to reduce risk

Hello everyone, This email is a continuation of https://groups.google.com/g/jenkinsci-dev/c/8cy8w7ZqyB8/m/eZfaenQzEAAJ. The "CERT" (= Security team) has access to some confidential information like not-yet-disclosed vulnerabilities, which fixes are in progress, internal discussions about pro

Re: Removing inactive CERT members to reduce risk

. On Monday, July 17, 2023 at 8:19:40 PM UTC+2 m...@basilcrow.com wrote: > On Fri, Jul 14, 2023 at 6:55 AM 'wfoll...@cloudbees.com' via Jenkins > Developers wrote: > > > > This email is a continuation of > https://groups.google.com/g/jenkinsci-dev/c/8cy8w7Zq

Re: Removing inactive CERT members to reduce risk

ess will follow soon. If you think your proposal should be implemented, I would suggest you to start a new thread, as it's beyond the original scopes of the existing ones. On Tuesday, July 18, 2023 at 4:59:19 PM UTC+2 m...@basilcrow.com wrote: > On Tue, Jul 18, 2023 at 1:05 AM 'wfoll.

Re: [Information] Release block "Beta" program

ings >> like enabling auto merge for when the release block is over >> >> On Tue, 5 Sep 2023 at 17:13, 'wfoll...@cloudbees.com' via Jenkins >> Developers wrote: >> >>> Dear plugin maintainers, >>> >>> *Context* >>> In situat

Re: [Information] Release block "Beta" program

sters. On Wednesday, September 6, 2023 at 1:51:18 PM UTC+2 timja...@gmail.com wrote: > On Wed, 6 Sept 2023 at 12:42, 'wfoll...@cloudbees.com' via Jenkins > Developers wrote: > >> Last time we tested, the branch locking has the problem to be visible for >> anyone. Thi

Re: CVE-2023-50164 Struts question

Hello Randall, If it's for a single plugin, the easiest way is to use `mvn dependency:tree` to check if you are using Struts or not. Usually if you include Struts indirectly (through transitive dependencies) there is low likelihood that you are effectively using it. Most of the Jenkins plugins

Re: [Proposal] Remove "hacktoberfest" topic from all jenkinsci repositories

Great, "more" work on the maintainer but it will be explicit opt-in, +1 On Thursday, September 12, 2024 at 10:08:58 AM UTC+2 bma...@gmail.com wrote: > Great idea, makes sense to me. It should also reduce the risk that some > participants never receive feedback on a PR submitted on a since-abando

Re: OSU OSL survey of open source developers

FTR I got "Sorry, this survey is not currently active.", after 8 days, not sure it's expected. On Monday, January 27, 2025 at 10:52:05 PM UTC+1 Mark Waite wrote: > The Oregon State University Open Source Laboratory has been a Jenkins > sponsor for many years. We continue to rely on them for tw

Re: Artifact storage reduction project

Hello Mark, >From my PoV, this access can be granted for this project. It has to be *temporary* as Darin is not part of the infra team. I would prefer for the next such occurrence, to have the infra team working on it, to reduce the need to grant permission to other people. The permissions are