"Fossies" - the Fresh Open Source Software Archive
Member "jenkins-jenkins-2.249.3/docs/MAINTAINERS.adoc" (4 Nov 2020, 28726 Bytes) of package /linux/misc/jenkins-jenkins-2.249.3.tar.gz:
As a special service "Fossies" has tried to format the requested text file into HTML format (style: standard
) with prefixed line numbers.
Alternatively you can here view
the uninterpreted source code file.
2 :toclevels: 3
4 = Documentation for core maintainers
8 Jenkins core is a central component of the project which serves millions of users, and it is critical to maintain it in a good shape.
9 We want to ensure quality of the integrated changes and continuity of the project,
10 and hence the Jenkins core pull request review and merge process is more sophisticated than for the majority of plugins.
12 == Scope of the document
14 This document applies to the following components:
16 * Jenkins core
17 * Jenkins modules
18 * Libraries included into the Jenkins core
19 * Core components like Winstone, Executable WAR, etc.
21 Jenkins Remoting library is not in the scope for this document,
22 because it is handled as a sub-project with independent maintainer team.
23 Remoting updates in the core are subject to the process though.
25 == Team
27 === Communication channels
29 * Mailing list: link:https://groups.google.com/d/forum/jenkinsci-dev[Jenkins Developer Mailing List]
30 * Chat for runtime Jenkins release coordination: `#jenkins-release` on Freenode IRC
31 ** All async communications should go to the developer mailing list
33 === Roles
35 * Contributor
36 * Issue Triage Team Member
37 * Core Pull Request Reviewer
38 * Core Maintainer
39 * Release Team Member
41 **Contributors** submit pull requests to the Jenkins core and review changes submitted by others.
42 There is no special preconditions to do so.
43 Anyone is welcome to contribute.
45 **Issues Triage Team Members** review the incoming issues submitted in Jenkins Jira:
46 bug reports, requests for enhancement, etc.
47 Special permissions are not required to take this role or to contribute.
48 Anyone is welcome to start contributing (see the <<issue-triage,triage guidelines below>>).
50 **Core Pull Request Reviewers** is a team for contributors who are willing to regularly review Jenkins pull requests and to eventually become Jenkins core maintainers.
51 They get https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/repository-permission-levels-for-an-organization[Triage permissions] so that they can manage pull requests, request reviews and prepare changelog drafts in the pull request description.
52 Their main responsibility is to triage and review the incoming pull requests,
53 and to guide newcomer contributors who are not familiar with the project's processes.
54 GitHub team: link:https://github.com/orgs/jenkinsci/teams/core-pr-reviewers[@jenkinsci/core-pr-reviewers].
56 **Core Maintainers** get `Write` permissions in the repository, and hence they are able to merge pull requests.
57 Their responsibility is to perform pull request reviews on a regular basis and to merge ready pull requests towards the weekly releases (`master` branch).
58 They are also responsible to monitor the weekly release status and to perform triage of critical issues.
59 GitHub team: link:https://github.com/orgs/jenkinsci/teams/core[@jenkinsci/core].
61 **Release Team Members** are responsible for Jenkins weekly and LTS releases.
62 Led by the link:https://jenkins.io/project/team-leads/#release[Jenkins Release Officer], they initiate releases, prepare changelogs and backport changes into the link:https://jenkins.io/download/lts/[Stable release line].
63 Team members get `Write` permissions in the Jenkins core repository, and they also get permissions to trigger release Pipelines.
65 === Ladder
67 * **Contributors**. Anyone can participate.
68 There is no precondition except having a GitHub account, just submit pull requests or comment in existing ones!
69 * **Core Pull Request Reviewers** can be nominated by contributors in the link:https://groups.google.com/d/forum/jenkinsci-dev[developer mailing list].
70 Self-nomination is fine.
71 Decision is made by a consensus in the mailing list or via voting at the link:https://jenkins.io/project/governance-meeting/[governance meeting].
72 * **Core Maintainers** - same process as for Core PR reviewers.
73 All nominees must also sign an link:https://github.com/jenkinsci/infra-cla/[Individual Contributor License Agreement] before getting the permission in GitHub repositories.
74 * **Release Team Members** are assigned by the Jenkins Release officer
76 == Pull request review process
78 Jenkins core is a mission-critical part of the ecosystem.
79 We need to ensure that submitted pull requests are not only code complete,
80 but also that they do not introduce undesired defects, breaking changes and technical debt.
81 At the same time, we are interested to make the review process as simple as possible for contributors and maintainers.
83 === Review goals
85 Pull requests review in Jenkins is not just about reviewing code and accepting them if the code is OK.
86 Core maintainers are expected to ensure feasibility and compatibility of changes,
87 to maintain good quality of the codebase and documentation,
88 and to ensure there is a consensus between contributors.
90 ==== Verifying Feasibility
92 Reviewers are expected to look at changes critically from a "product management" point of view.
93 It's not just about the code, but also whether the change makes sense in a global / holistic way, considering existing popular plugins and the way users experience Jenkins overall.
94 Also, not every change needs to be merged into the core.
95 Many features would be better introduced as plugins which have separate release cycles and allow delivering changes faster.
96 We want to extend the Jenkins core and incorporate widely used functionality and extension points there,
97 but we try to keep the core as minimal as possible in terms of dependencies.
99 ==== Ensuring Compatibility
101 The Jenkins project has a long history of backward compatibility.
102 We accept breaking changes when it is needed (security fixes, feature deprecation and removal, etc.),
103 but ultimately the project's goal is retain as much compatibility as possible.
104 It includes both feature compatibility and binary/API compatibility which is important for the plugin ecosystem.
105 Although we have some tools (like https://github.com/jenkins-infra/usage-in-plugins[usage-in-plugins]) for checking API usages across open-source plugins,
106 there is no way to confirm external usages in 3rd-party proprietary plugins which are also a part of the ecosystem.
108 ==== Maintaining Code quality
110 The code doesn't have to be perfect, but we want to ensure that all new code matches basic quality standards:
111 test coverage for newly added functionality and fixes,
112 documentation for newly introduced APIs,
113 the submitted code is readable and matches the code style in the surrounding codebase,
116 ==== Code style
118 We're aware that there are existing inconsistencies in the code,
119 and we do not enforce a single code style across the codebase at the moment.
121 * New code should follow the (majority) style guide.
122 In Jenkins core we use the link:https://www.oracle.com/technetwork/java/codeconvtoc-136057.html[these Code Conventions for the Java TM Programming Language] as a default code style
123 * Updates to existing code should only fix formatting on the lines affected anyway to keep the diff minimal.
124 It helps reviewers focus their attention on the specifics of the change and reduces the risk of a change from one pull request creating a conflict in another pull request.
126 ==== Maintaining documentation
128 * Jenkins documentation is hosted on https://jenkins.io/doc/.
129 When a new user-facing change is added, we should encourage contributors to update documentation in downstream pull requests.
130 * Same applies to Jenkins changelogs (link:https://jenkins.io/changelog[weekly], link:https://jenkins.io/changelog-stable/[stable]) and link:https://jenkins.io/doc/upgrade-guide/[upgrade guidelines]:
131 We have a semi-automated process which is based on pull request summaries and labels.
132 Core maintainers are expected to validate the entries as a part of the pull request review/merge process.
133 See the checklist below in the _Merge process_ section.
135 ==== Building consensus
137 Not all changes are discussed before they are submitted as pull requests.
138 Developer mailing lists, Jira issues and JEPs are used for discussions,
139 but sometimes the changes go straight to the pull requests.
140 And we are fine with that, especially for small patches.
141 Pull requests often become a venue to discuss feasibility, underlying technical decisions and design.
142 We are fine with that as well.
143 If there is no consensus about the feasibility and implementation,
144 code reviewers are expected to suggest proper channels for contributors to discuss their contribution.
146 * A discussion in the link:https://groups.google.com/d/forum/jenkinsci-dev[Jenkins Developer Mailing List] is the default way to go
147 * If no consensus can be reached on the mailing list,
148 voting at the link:https://jenkins.io/project/governance-meeting/[Jenkins Governance Meeting] can be used to get a final decision.
150 === Review non-goals
152 Code reviews do NOT pursue the following goals:
154 * Accepting/merging any pull request.
155 Not everything is going to be merged, and reviewers are expected to focus on the Jenkins ecosystem integrity first.
156 We guide contributors and help them to get their changes integrated, but it needs cooperation on both sides.
157 It is **fine** to close invalid and inactive pull requests if there is no activity by a submitter or other contributors.
158 * Enforcing a particular coding style.
159 Jenkins core has a complex codebase created by many contributors, and different files have different designs.
160 Our main goal is to firstly have the code readable by other contributors.
161 * Make contributors fix issues that are not related to the primary topic of the pull request
162 ** Create follow-up issues instead, it is fine to reference them in comments so that the contributor might want to pick them up
163 * Make contributors to have atomic commit history or to squash their pull request
164 ** Not every contributor is a Git expert, do not request changes in the commit history unless it is necessary
165 ** Core maintainers can squash PRs during the merge.
166 If you feel this is important, add the link:https://github.com/jenkinsci/jenkins/pulls?q=is%3Aopen+is%3Apr+label%3Asquash-merge-me[squash-merge-me] label
167 ** We want to keep pull requests focused when possible (one feature / fix per pull request),
168 but we can live without it if there is no need to backport changes to the stable baseline.
170 == Issue triage
172 Jenkins core and most of its components use link:https://issues.jenkins-ci.org/[Jenkins Jira] as an issue tracker.
173 This issue tracker is open to all Jenkins users.
174 They report defects and requests for enhancements,
175 and then component maintainers triage issues and provide feedback to users.
176 In the case of the Jenkins core, *Issue Triage Team* and *Core Maintainers* are roles who are expected to process the incoming issues.
177 These contributors perform initial triage of incoming issues and periodically scrub the issue tracker.
179 This section provides some tips and tricks about triaging issues submitted to the Jenkins core.
181 === Issue tracker structure
183 Jenkins core uses the link:https://issues.jenkins-ci.org/projects/JENKINS[JENKINS] project for issue tracking.
184 This project is shared between the Jenkins core components and plugins,
185 and the Jenkins core is scattered across multiple components: `core`, `remoting`, `cli`, `winstone-jetty`, etc.
186 In addition to it, there is a default `_unsorted` component which is recommended by default for users
187 who do not know what is the root cause of an issue they experience.
189 Searching for all Jenkins core issues is not trivial, and we provide Jira filters for it.
191 === How to discover untriaged issues?
193 * Community rating in Jenkins link:https://www.jenkins.io/changelog/[Regular (Weekly)]
194 and link:https://www.jenkins.io/changelog-stable/[LTS] releases.
195 Such ratings allow users to reference issues they experienced with new Jenkins core releases,
196 and it helps to discover regressions in the core causing instability or unexpected plugin failures.
197 * link:https://issues.jenkins-ci.org/secure/Dashboard.jspa?selectPageId=20742[Jenkins core triage board] -
198 Lists untriaged and recent issues in the Jenkins core and bundled components.
199 * link:https://issues.jenkins-ci.org/secure/Dashboard.jspa?selectPageId=20340[Core maintainers board] -
200 Lists unresolved recent regressions, unresolved recent core bugs, and popular new issues.
201 This dashboard can be used to discover issues that **might** be related to the recent changes in the Jenkins core.
203 === HOWTO: Initial triage
205 Initial issue triage has the following objectives:
207 * **Perform initial triage of an issue**.
208 Issue triage team members are not expected to perform a full analysis of the issue (though they are welcome to do so!).
209 The main goal is to ensure that an issue report is legitimate and that it contains enough information to be processed.
210 It is fine to request additional information from submitters and/or to refer them to reporting guidelines:
211 ** link:https://www.jenkins.io/participate/report-issue/[Guide: How to report an issue in Jenkins]
212 ** link:https://github.com/jenkinsci/remoting#reporting-issues[Reporting Jenkins Remoting issues]
213 * **Verify the issue component**.
214 It is essential to ensure that the `component` field references the right component (the Jenkins core, a plugin, etc.)
215 so that an issue can be discovered and processed by a component maintainer.
216 When moving an issue, assign the issue to the `automatic` assignee so that the maintainer gets a notification.
217 Not all components have a default assignee, and it is perfectly fine to leave the assignee field empty.
218 * **Verify the issue type**.
219 `Bug` should be used for bug reports.
220 All other issue types are considered as requests for enhancements, and there is no practical difference for the Jenkins core.
221 * **Verify the issue metadata**: Jenkins version, environment, labels, etc.
222 Such metadata is useful for further triage and issue discoverability.
223 There are some labels used in Jenkins Jira dashboard and filters, e.g. `jcasc-compatibility`, `java11-compatibility`, `jep-200`, etc.
224 Assigning such labels helps users and maintainers to discover issues and act on them.
225 There is no list of such "common labels" recommended for use.
226 Some labels can be found in similar issues or documentation linked from system log entries in the reports.
227 * **Move security issue** to the `SECURITY` project.
228 Sometimes the issue reporters do not follow the link:https://www.jenkins.io/security/#reporting-vulnerabilities[vulnerability reporting] process and report security issues in public.
229 If you see such issues, move them to the `SECURITY` project so that the security team takes care of their triage.
230 Note that the required fields are different between projects, so some manual updates might be required when moving them.
231 * **Label regressions and CC stakeholders** if an issue is reported as a regression with a clear root cause,
232 please set a `regression` label and, if applicable, CC contributors of a change which led to the regression.
233 * **Resolve invalid issues and support requests**.
234 Sometimes Jenkins Jira is used as a support portal.
235 We do not want to encourage that.
236 Jenkins Jira is an issue tracker, and we expect reporters to investigate issues on their side to an extent that they can be reviewed by maintainers.
237 For support requests users are expected to use link:https://www.jenkins.io/mailing-lists[mailing lists],
238 link:https://www.jenkins.io/chat/[chats] and other resources (e.g. Stackoverflow).
239 It is fine to link users to link:https://github.com/jenkinsci/.github/blob/master/SUPPORT.md[this page].
240 * **Resolve duplicates**.
241 It is often that the same issue is already reported in the Jenkins database.
242 Newly reported duplicates can be just resolved with a `Duplicate` resolution, and linked to the original issue.
244 === HOWTO: Triage by maintainers
246 Further triage focuses on confirming the issue and defining a potential resolution.
247 It can be performed by _Issue Triage Team Members_ if they want to dive deeper,
248 or they can leave it to component maintainers.
250 Triage objectives:
252 * **Confirm reported defects**. Try to reproduce the issue or analyze the codebase.
253 If the issue is legitimate, it is great to explicitly confirm it in a comment.
254 * Nice2Have: **Define next steps**.
255 If possible, define a potential resolution for the issue.
256 If you do not plan to work on the issue in foreseeable future,
257 it is great to explicitly highlight that by unassigning the issue and inviting the reporter and other contributors to submit a fix.
258 * Nice2Have: **Highlight newcomer-friendly issues**.
259 Newcomer-friendly issues are instrumental for an onboarding new code contributors to the project.
260 They are linked from link:https://www.jenkins.io/participate/code/[contributing guidelines].
261 If you see a simple issue but do not plan to work on it,
262 put a `newbie-friendly` label on it so that somebody could pick it up.
264 === How to scrub issues?
266 In addition to the initial triage, it is a good practice to sometimes review previously reported issues so that we could minimize backlog of issues and simplify search by users.
268 * **Triage reopened issues**.
269 Same as for newly reported issues, it is great to process reopened issues if they are not acted on by the issue assignees.
270 Often such issues can be resolved with a request to report a new issue if an issue is reopened due to another issue.
271 * **Resolve stale untriaged issues**.
272 Issue reporters may become unresponsive before their issue can be fully triaged.
273 If there is a reported issue which does not contain data for reproducing the issue,
274 it is fine to resolve them after a 2-week timeout with the `Incomplete` or `Cannot reproduce` resolution.
275 * **Resolve/update obsolete issues**.
276 Sometimes issues become obsolete due to other changes in the Jenkins core (e.g. feature removal),
277 and such issues can be closed.
278 Same for detaching functionality from the Jenkins core and plugins,
279 issues can be reassigned to the new Jira component so that they are removed from the core backlog.
281 === Triaging requests for enhancement
283 Requests for enhancement (RFEs) include the `New Feature` and `Improvement` types in Jenkins Jira.
284 The process to triage them might be different than bug reports.
285 because it is not always possible to say whether a request should be implemented in the Jenkins core,
286 an existing or a new plugin.
287 In the case of doubt, it is fine to just skip an issue or CC subject matter experts who could advice.
289 For RFEs which are not related to the Jenkins core or plugins,
290 it is possible to set the `plugin-proposals` component.
291 Note that this component is not regularly scrubbed,
292 and it can be considered only as a pool of ideas somebody could implement.
293 It is a good practice to set expectation in a comment when updating the RFE.
295 === Responding to pings in triaged issues
297 Some submitters and users tend to ping triage contributors to ask about the fix ETA.
298 In some cases, they may also assign the issue and keep pinging.
299 It is fine to not answer these questions on such pings and to refer requestors to this document,
300 triage team members are not responsible for handling the ticket after initial triage.
302 Other materials which might help:
304 * link:https://www.jenkins.io/participate/code/[Contribute to Jenkins / Code] or
305 link:https://github.com/jenkinsci/jenkins/blob/master/CONTRIBUTING.md[Contributing to the Jenkins Core] -
306 extended version of "feel free to contribute".
307 * link:https://github.com/jenkinsci/.github/blob/master/SUPPORT.md[Jenkins Support Disclaimer Page] -
308 for those requesters who expect quick response and SLA.
309 * link:https://www.jenkins.io/doc/developer/plugin-governance/adopt-a-plugin/[Plugin Adoption Policy] -
310 for pings in not actively maintained components.
311 * link:https://www.jenkins.io/project/conduct/[Jenkins Code of Conduct] -
312 when it gets ugly.
314 === Resolving vs. Closing issues
316 Jira workflow for the `JENKINS` project has two similar states: `Resolved` and `Closed`.
317 Historically the issues are rarely being **closed**, and all dashboard and Jenkins processes interpret resolved issues as closed.
318 The main difference is that the _Resolved_ issues can be reopened by users while _Closed_ ones can be reopened by admins only.
320 For triage purposes, it is recommended to use the `Resolved` state if there is a chance that the issue will be reopened by the reporter or other contributor
321 (e.g. resolving due to inactivity, disagreement with the resolution, etc.).
323 == Merge process
325 === Common merge process
327 ==== Step 1: Maintainer checklist
329 Merge process can be initiated once a pull request matches the requirements:
331 * Pull request is compliant with requirements to submitters (see the link:/.github/PULL_REQUEST_TEMPLATE.md[pull request template])
332 * There are at least 2 approvals for the pull request and no outstanding requests for change
333 * Conversations in the pull request are over OR it is explicit that a reviewer does not block the change (often indicated by line comments attached to an approving PR review, or by using the term "nit", from "nit-picking")
334 * Changelog entries in the PR title and/or _Proposed changelog entries_ are correct and reflect the current, final state of the PR
335 * Proper changelog labels are set so that the changelog can be generated automatically.
336 List of labels we use for changelog generation is available link:https://github.com/jenkinsci/.github/blob/master/.github/release-drafter.yml[here].
337 * If the change needs administrators to be aware of it when upgrading, the `upgrade-guide-needed` label is present
338 and there is a `Proposed upgrade guidelines` section in the PR title
340 This is usually the case when a data migration occurs, a feature has been removed, a significant behavior change is introduced (including when there is a way to opt out),
341 or in general when we expect at least a large minority of admins to benefit from knowing about the change, e.g. to apply a new option.
342 * If it would make sense to backport the change to LTS, a Jira issue must exist, be a _Bug_ or _Improvement_, and be labeled as `lts-candidate` to be considered (see link:https://issues.jenkins-ci.org/issues/?filter=12146[this Jira query]).
344 ==== Step 2: Is it a good time to merge?
346 link:https://jenkins.io/security/[Jenkins security updates] are coordinated with the LTS calendar and if the weekly release on the weekend before an LTS release introduces regressions, users of the weekly line may have to choose between security fixes and a working Jenkins.
347 The Jenkins security team will usually send a "pre-announcement" to link:https://groups.google.com/forum/#!forum/jenkinsci-advisories[the advisories list] on Wednesday or Thursday the week before release, but that's not always doable.
348 For these reasons, the following changes should not be merged during the week before LTS releases (weeks 3, 7, 11, 15, etc. on the page linked above):
350 * Changes that could be considered risky (relatively high risk of introducing regressions), as they could make users of Jenkins weekly releases choose between getting security fixes, and having a functioning Jenkins
351 * Very large changes (in terms of lines changed), because the Jenkins security team needs to prepare security fixes for the weekly release line in a very short period of time.
353 If the change is ready but it is not a good time, consider labeling the pull request with the `on-hold` label.
354 Make sure to add a comment explaining why it was put on hold.
356 ==== Step 3: Marking for merge
358 Once the checklist is passed, a Core PR Reviewer or a Maintainer can mark the pull request for merge.
360 * `ready-for-merge` label is set
361 * An explicit comment is added to the pull request so that other repository watchers are notified.
362 Example: _Thanks to all contributors! We consider this change as ready to be merged towards the next weekly release. It may be merged after 24hours if there is no negative feedback_
364 ==== Step 4: Merge!
366 A Core Maintainer merges the change after allowing sufficient time for comment (if needed).
367 After that the change will be landed in the next weekly release.
368 LTS backporting, if needed, will be handled separately by the release team.
370 === Exceptions
372 * Jenkins Security Team uses a different process for security issue fixes.
373 They are reviewed and integrated by the Security team in private repositories.
374 Security hardening and enhancements go through the standard process.
375 * Release Team members are permitted to bypass the review/merge process if and only if a change is needed to unblock the security release.
376 Common review process is used otherwise.
377 * 24 hours waiting period after adding the `ready-for-merge` label is not required for:
378 //TODO(oleg_nenashev): Define "trivial" better to avoid loopholes
379 ** changes that do not result in changes to the primary functionality, such as typo fixes in documentation or localization files
380 ** changes which do not affect the production code: Jenkinsfile tweaks, tools inside the repo, etc.
381 ** broken master build
383 === Squashing pull requests OR not?
385 Sometimes we have pull requests which include dozens of commits including many non-substantial changes (merge commits, addressing review comments, etc.).
386 We do not require contributors to spend time on cleaning it up, because core maintainers can squash PRs during the merge.
387 Reviewers can add a link:https://github.com/jenkinsci/jenkins/pulls?q=is%3Aopen+is%3Apr+label%3Asquash-merge-me[squash-merge-me] label during reviews to highlight that it is needed.
389 At the same time, we do not require any pull request to be merged as a single commit.
390 Multiple commits are useful in many cases.
392 When do we merge pull requests as is?
394 * There is only one commit with a reasonable commit message
395 * There are multiple atomic commits. Each commit has a reasonable message and can be compiled on its own
396 ** Example:
397 *** **Commit 1**: `[JENKINS-1234] - Reproduce the issue in tests`
398 *** **Commit 2**: `[JENKINS-1234] - Fix the issue by updating Foo`
399 * There are multiple commit authors who expressed the desire to keep commit history as is.
400 By default we do not consider multiple authors as a blocker for squash, because GitHub now
401 link:https://help.github.com/en/github/committing-changes-to-your-project/creating-a-commit-with-multiple-authors[supports co-authors]
403 When do we squash commits?
405 * We squash commits when core maintainers decide to do so (`squash-merge-me` label), usually when the conditions above are not met.
406 * There is no strong requirement to squash merge pull requests at the moment, so there might be deviations from the merge policy in practice.
408 == Weekly release process
410 link:https://www.jenkins.io/download/weekly/[Jenkins Weekly releases] are managed by the Jenkins Release Team which has access to the dedicated release environment within the Jenkins Infrastructure.
413 * link:https://www.jenkins.io/download/weekly/[Jenkins Weekly Releases Documentation]
414 * link:https://github.com/jenkins-infra/release[Jenkins Release Environment and the release process]
415 * link:https://github.com/jenkinsci/packaging[Native Jenkins packages and installers for platforms]
416 * link:https://github.com/jenkinsci/docker[Docker packaging for Jenkins]
418 == LTS Process
420 Jenkins also offers the link:https://jenkins.io/download/lts/[LTS Release Line].
421 It is maintained by the Jenkins Release Team which coordinates link:https://jenkins.io/download/lts/#backporting-process[backporting] and release candidate testing.
422 Any Jenkins contributors are welcome to participate in backporting and release candidate testing.
424 * Backporting discussions happen through the developer mailing list.
425 * Backports are submitted as pull requests with the link:https://github.com/jenkinsci/jenkins/labels/into-lts[into-lts] label.
426 * Release candidate testing is announced in the developer mailing list.
427 Discovered issues should be submitted to Jenkins Jira and then referenced in the release candidate testing thread.
429 == Tools
431 * link:https://issues.jenkins-ci.org/secure/Dashboard.jspa?selectPageId=20340[Core maintainers board] -
432 Lists unresolved recent regressions, unresolved recent core bugs, and popular new issues.
433 * link:https://github.com/jenkinsci/core-pr-tester[Core Pull Request Tester]
434 * link:https://github.com/jenkinsci/core-changelog-generator[Core Changelog Generator]
435 * link:https://github.com/jenkins-infra/backend-commit-history-parser[Toolkit for LTS backporting]
436 * link:/update-since-todo.sh[Javadoc @since version updater]
438 == Feedback
440 The process documented in this document is not set in stone.
441 If you see any issues or want to suggest improvements,
442 just submit a pull request or contact us in the communication channels referenced above.
443 Any feedback will be appreciated!