Author: svn-site-role Date: Sat Dec 6 21:46:49 2025 New Revision: 1930296 Log: Site checkin for project Apache Maven Site
Modified: maven/website/content/developers/conventions/git.html maven/website/content/developers/conventions/github.html maven/website/content/project-roles.html Modified: maven/website/content/developers/conventions/git.html ============================================================================== --- maven/website/content/developers/conventions/git.html Sat Dec 6 18:45:03 2025 (r1930295) +++ maven/website/content/developers/conventions/git.html Sat Dec 6 21:46:49 2025 (r1930296) @@ -174,8 +174,8 @@ under the License. <li>Make a pull request to pull your changes to the official clone.</li> </ol></section><section><a id="For_committers"></a> <h3>For committers</h3> -<p>Committers may, of course, commit directly to the ASF repositories. For complex changes, you may find it valuable to make a pull request at GitHub to make it easier to collaborate with others.</p><section><a id="Commit_Message_Template"></a> -<h4>Commit Message Template</h4> +<p>Committers may, of course, commit directly to the ASF repositories. For complex changes, you may find it valuable to make a pull request at GitHub to make it easier to collaborate with others.</p></section><section><a id="Commit_Message_Template"></a> +<h3>Commit Message Template</h3> <p>Commits should be focused on one issue at a time, because that makes it easier for others to review the commit.</p> <p>While not mandatory, we will appreciate signed commits.</p> <p>If the changes is linked to an issue, the commit message should use this template:</p> @@ -196,9 +196,17 @@ o Comments Submitted by: Baz Bazman o Applied without change -</code></pre></section></section></section><section><a id="Apply_User_Patch"></a> +</code></pre></section></section><section><a id="Review_policy"></a> +<h2>Review policy</h2> +<p>The Maven project has no strict review policy, but the following practices established:</p> +<ul> + +<li><em>Commit Then Review (CTR)</em> for trivial/simple changes</li> +<li><em>Review Then Commit (RTC)</em> for complex changes and changes against release branches of past releases (e.g. <code>maven-3.8.x</code> branch)</li> +</ul> +<p>Committers are invited to also request reviews for trivial changes, because every review can increase code quality.</p></section><section><a id="Apply_User_Patch"></a> <h2>Apply User Patch</h2> -<p>To keep the history of contributions clear, The committer should usually apply the patch without any <strong>major</strong> modifications, and then create his or her own commits for further modifications. However, committers should never commit code to a live branch which is not suitable to release. If a contribution requires significant work to make it useful, commit it to a branch, fix it up, and merge the branch.</p> +<p>To keep the history of contributions clear, the committer should usually apply the patch without any <strong>major</strong> modifications, and then create his or her own commits for further modifications. However, committers should never commit code to a live branch which is not suitable to release. If a contribution requires significant work to make it useful, commit it to a branch, fix it up, and merge the branch.</p> <p>If the user created a pull request, the committer is responsible for closing that pull request. You do this by adding a note to a commit message:</p> <pre><code class="nohighlight nocode">Closes #NNN. Modified: maven/website/content/developers/conventions/github.html ============================================================================== --- maven/website/content/developers/conventions/github.html Sat Dec 6 18:45:03 2025 (r1930295) +++ maven/website/content/developers/conventions/github.html Sat Dec 6 21:46:49 2025 (r1930296) @@ -184,7 +184,8 @@ to prepare Release Notes.</p> <p>Committers can assign a GitHub Issue or Pull Request to a specific committer if that person seems to be well-placed to address it.</p></section><section><a id="Reviewers"></a> <h3>Reviewers</h3> -<p>We should invite persons to review for every change, even it is simply one, review can increase code quality.</p></section><section><a id="Priority"></a> +<p>We should invite persons to review for every change, even it is simply one, review can increase code quality. +Also see <a href="./git.html#review-policy">Maven's review policy</a>.</p></section><section><a id="Priority"></a> <h3>Priority</h3> <p>For priority (equivqlent to <a href="https://confluence.atlassian.com/adminjiraserver/defining-priority-field-values-938847101.html"; class="externalLink">Jira Priority</a>), we can use GitHub Issues <a href="https://docs.github.com/en/issues/using-labels-and-milestones-to-track-work/managing-labels"; class="externalLink">labels</a>:</p> <ul> Modified: maven/website/content/project-roles.html ============================================================================== --- maven/website/content/project-roles.html Sat Dec 6 18:45:03 2025 (r1930295) +++ maven/website/content/project-roles.html Sat Dec 6 21:46:49 2025 (r1930296) @@ -250,8 +250,7 @@ take a formal role in our project.</p></ <p>These are those people who have been given write access to the Apache Maven code repository and have a signed <a href="https://www.apache.org/licenses/#clas"; class="externalLink">Contributor License Agreement (CLA)</a> on file with the ASF.</p> -<p>The Apache Maven project uses a Commit then Review policy and has -<a href="/developers/index.html#Developers_Conventions">a number of conventions</a> which should be followed.</p> +<p>The Apache Maven project has a number of <a href="/developers/index.html#Developers_Conventions">conventions</a> which should be followed.</p> <p>Committers are responsible for ensuring that every file they commit is covered by a valid CLA.</p> <p>Committers who would like to become PMC members should try to find @@ -271,7 +270,7 @@ policy is that committer role reinstatem controls the project. Membership of the Project Management Committee is decided by the board of the Apache Software Foundation, based on nominations from the Project Management Committee.</p> -<p>It is a long standing tradition of the Apache Maven Project that +<p>It is a long-standing tradition of the Apache Maven Project that the Project Management Committee reviews the active committers approximately every 6 months with a view to determining whether any of those committers would be suitable candidates to @@ -295,7 +294,7 @@ If a PMC member wants the project to be from the PMC stating their reason. If the PMC shrinks beyond the minimal viable size, then as a result of a desire by the bulk of the PMC to move the project elsewhere, the Board of the Apache Foundation will take that into account -when moving the project into the Foundation's <a href="https://attic.apache.org"; class="externalLink">Attic</a>);</li> +when moving the project into the Foundation's <a href="https://attic.apache.org"; class="externalLink">Attic</a>;</li> <li>Prepare <a href="https://whimsy.apache.org/board/minutes/Maven.html"; class="externalLink">reports</a> as required by the Board of the Apache Foundation and ensure those reports are ready for presentation by the PMC Chair in a timely manner.</li> @@ -357,7 +356,7 @@ roadmap has been agreed).</li> is committed to the project's source control as early as possible. Similarly small commits are easier to review than large commits.</p> <p>There is nothing inherently wrong with maintaining a fork of the Maven -codebase outside of the Apache Foundation. Individual developers can have +codebase outside the Apache Foundation. Individual developers can have their own style of working and may prefer to work in a fork so that they can throw away failed experiments with less visibility (though it could be argued that the visibility of such failed experiments can be valuable @@ -377,8 +376,8 @@ and history re-written to mask or otherw This does not mean that code coming from an external fork inherently has such issues. Instead, it means that the requirements for review and verification of provenance grow exponentially when dealing with large sets of changes -originating from a long running fork hosted outside of Apache foundation -source control. Anybody maintaining a long running fork should be aware +originating from a long-running fork hosted outside of Apache foundation +source control. Anybody maintaining a long-running fork should be aware that review obligations may grow above the time capabilities of the PMC and committers. When they eventually try to bring the changes in their fork back to the Apache Maven project, their @@ -394,7 +393,7 @@ the project management committee. They d additional gravitas in the project. It is the Project Management Committee as a whole that is responsible for the direction of the project.</p> <p>If things break down and there is no consensus and there is no clear -ability to reach any conclusion <em>and</em> it is in the interest of the +ability to reach any conclusion, <em>and</em> it is in the interest of the foundation because damage is done and the board expects the chair to act as an officer of the foundation and clean things up, then the chair can act as an ultimate decision maker. However, by this point the
