Unfortunately I will be unable to attend the upcoming contributor summit. I’m bummed out to be missing out on such a wonderful experience and gathering, but I’m excited for everyone to meet and share in the project!
1 Like
Thanks for letting us know, Kevin. 
It’s unfortunate you can’t make it. 
We’ll strive to ensure it’s a pleasant experience for everyone.
In 2024, this gathering acted as a catalyst for several important sub-projects. I sincerely hope we can replicate that success in 2025.
I propose a topic that Basil Crow and I can share together, with most of the experience coming from Basil
- Compatible migrations - Spring Security 6, Jakarta EE 9, Eclipse Jetty 12
- Alternatives that were considered
- Discovery process using acceptance test harness
- Compatibility layer implementation pattern
- Plugin updates to require Jenkins 2.479.1 or newer
- Jakarta EE 9 transition
- Spring Security 6 transition
- Testing for compatibility
- When a plugin needs to provide a compatibility layer for other plugins
- Identifying and exploring compatibility risks
1 Like
I’m hoping to attend
1 Like
will it be available online?
No, this is a face to face event. We’re not likely to attempt a broadcast from the face to face event because we don’t want the additional complications of broadcasting.
Definitely not. I’ve been there and done that for other events, and it’s a full-time job.
Agenda:
- Morning
- Welcome and practical details
- “The Present and the Future. The Jenkins Board and Officer’s view”
- Jenkins Board presentation
- Jenkins Infrastructure officer
- Jenkins Release officer
- Documentation officer
- Events officer
- Security officer
- User Experience SIG report
- Lunch break (1h)
- Afternoon
- Modernizing Plugins
- Platform SIG report
- Java Support plan
- Compatible migrations - Spring Security 6, Jakarta EE 9, Eclipse Jetty 12
- Alternatives that were considered
- Discovery process using acceptance test harness
- Compatibility layer implementation pattern
- Plugin updates to require Jenkins 2.479.1 or newer
- Jakarta EE 9 transition
- Spring Security 6 transition
- Testing for compatibility
- When a plugin needs to provide a compatibility layer for other plugins
- Identifying and exploring compatibility risks
- Jenkins User Experience evolution
- Open discussion: Initiatives and Roadmap
- Workshops
- Plugin modernization brainstorming
- Coding Workshop
Feel free to propose other subjects you want to see presented or discussed.
The Contributor Summit will take place in 2025 at the same venue as in 2024, Beta Cowork, located at Rue des Pères Blancs 4, 1040 Brussels, Belgium.
1 Like
Looking forward to attend. Thanks in advance to anyone for their effort in organizing the summit!
I can’t wait to see you there, Daniel! 
1 Like
I will attend the contributor summit.
Is there any interest from the audience to have a brainstorming discussion on what could be Jenkins 3 / what are the plan for the future of the Jenkins project?
1 Like
Thanks, Wadeck!
In the breakout sessions, we could have a brainstorming discussion about your ideal vision for Jenkins 3. I understand that Basil has a lot of ideas and plans regarding the next major version of Jenkins too.
I still need to determine how much time to allocate to these breakout sessions since your input will also be critical in the Jenkins security/CSP future breakout session.
i’ll be there! Looking forward to seeing everyone 
2 Likes
Agenda:
- Morning
- Welcome and practical details
- “The Present and the Future. The Jenkins Board and Officer’s view”
- Jenkins Board presentation
- Jenkins Infrastructure officer
- Jenkins Release officer
- Documentation officer (or Authorized Representative)
- Events officer
- Security officer
- User Experience SIG report
- Lunch break (1h)
- Afternoon
- Platform SIG report
- Java Support plan
- Compatible migrations - Spring Security 6, Jakarta EE 9, Eclipse Jetty 12
- Alternatives that were considered
- Discovery process using acceptance test harness
- Compatibility layer implementation pattern
- Plugin updates to require Jenkins 2.479.1 or newer
- Jakarta EE 9 transition
- Spring Security 6 transition
- Testing for compatibility
- When a plugin needs to provide a compatibility layer for other plugins
- Identifying and exploring compatibility risks
- Modernizing Plugins
- Jenkins User Experience evolution
- Open discussion: Initiatives and Roadmap
- Breakouts
- Plugin modernization brainstorming
- Jenkins’ security near future
- Jenkins 3
- Coding Workshop
Feel free to propose other subjects you want to see presented or discussed.
Please note, we’ll have dinner after the summit, and will have to take the bus to reach the venue.
To the officers and board members: please update your section in the document we’ll be using during the summit.
Cheers, as first discussed in Gitter, I also plan to attend - now got the flight and bedding lined up for that too 
One question about the agenda (and the dinner after) - what are the expected wallclock times? e.g. does it start at 7? 8? 9? And what sort of “dinner” term meaning is implied, the one around noon/early afternoon, or the latest meal of the day? 
Another is for my parts of the agenda that I suggested in chat. I did not yet prepare anything (as in presentation or something), but generally would like to discuss (if of interest to those meeting up) a couple of subjects, which are not really new but still may be scratching not only my itches
- The Jenkins-dynamatrix JSL I’ve made for multi-platform projects to be built and tested on a population of build agents, provided by that project and/or its community members, so the build/test matrix is dictated by whatever agents and their abilities (toolkits, CPU arch, OS distro, etc.) are available.
- GitHub - networkupstools/jenkins-dynamatrix: A shared library to do a sort of matrix build based on available swarm agent labels
- Jenkins is the way to build multi-platform NUT
** There are some rough ideas how the swarm agent plugin could be improved, based on a few mishaps I’ve had with this approach and user-provided agents.
- Find some way to move forward with my old PR [JENKINS-64383] combined refrepo became our bottleneck, support a fanout location too by jimklimov · Pull Request #644 · jenkinsci/git-client-plugin · GitHub gathering dust, which is about a more flexible way to use Git reference repositories. When we had a large project ecosystem with many modules and their repos involved, a single refrepo (with many “remotes”) was usable but got slower and slower, to the point that checkouts over internet became better. Keeping co-located multiple repositories, with dedicated directories for forks or different URLs of same codebase, and having the Git Client plugin find the suitable one, solved the issue for us. The PR was posted 4 years ago but got stuck, IIRC, on incomplete self-tests and/or use of external scripts to keep the refrepo location with suggested layout up to date. Anyhow, this is code I use and rely on in many projects, it works and is battle-tested, and keeping the fork of the plugin built as the main code evolves is annoying. So getting it upstreamed is something I want to arrange, and it did not happen with some years of lazy attempts with online communications, and then dayjob interests taking back over
- And another PR, stuck for not so long, Hacktoberfest [JENKINS-69731] Enhance @Library annotation to load same version (feature branch name) of library as pipeline script from SCM by jimklimov · Pull Request #19 · jenkinsci/pipeline-groovy-lib-plugin · GitHub is about easier use of multi-branch shared libraries with multi-branch pipelines by requesting (literally)
@Library('libname@${BRANCH_NAME}')to get same branch name of a library as of the job itself, allowing for easier juggling of dev/staging/prod variants of CI itself. This bogged down in, IIRC, design discussions about how certain things could be made better and/or match some team ideas about long-term evolution of Jenkins. But again - this is code that works well, is relied on in a few projects I deal with, and I would love to see upstreamed so I don’t have to keep maintaining a fork of the plugin, and also that if someone has improvement ideas here or there, they can just post PRs as usual while everyone can benefit from code du jour
Hope this helps,
Jim Klimov