You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@maven.apache.org by cs...@apache.org on 2022/09/09 11:18:23 UTC

[maven-site] branch clearup-commit-policies created (now b62be904)

This is an automated email from the ASF dual-hosted git repository.

cstamas pushed a change to branch clearup-commit-policies
in repository https://gitbox.apache.org/repos/asf/maven-site.git


      at b62be904 [MNGSITE-491] Update commit policy related document

This branch includes the following new commits:

     new b62be904 [MNGSITE-491] Update commit policy related document

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.



[maven-site] 01/01: [MNGSITE-491] Update commit policy related document

Posted by cs...@apache.org.
This is an automated email from the ASF dual-hosted git repository.

cstamas pushed a commit to branch clearup-commit-policies
in repository https://gitbox.apache.org/repos/asf/maven-site.git

commit b62be90465a0bedb81e37be8d44fc79961b9fe6f
Author: Tamas Cservenak <ta...@cservenak.net>
AuthorDate: Fri Sep 9 13:17:09 2022 +0200

    [MNGSITE-491] Update commit policy related document
    
    Last update to ASF Maven commit policy happened while it sources
    were hosted in Subversion repository... Update relevant bits
    w/ respect to changes happened since then.
---
 content/apt/developers/conventions/git.apt |  8 ++++++--
 content/markdown/project-roles.md          | 22 ++++++++++++++++++----
 2 files changed, 24 insertions(+), 6 deletions(-)

diff --git a/content/apt/developers/conventions/git.apt b/content/apt/developers/conventions/git.apt
index f6b27e6b..4740d903 100644
--- a/content/apt/developers/conventions/git.apt
+++ b/content/apt/developers/conventions/git.apt
@@ -64,8 +64,12 @@ Maven Git Convention
 ** For committers
 
   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.
+  For complex changes or changes against stable branches it is required
+  to make a pull request at github to make it easier to collaborate with
+  others. For simple/trivial changes, it is okay for a committer to push
+  directly to repository and not create PR. Whether pull requests are created
+  from branch pushed to ASF repository or from developer own
+  personal fork, is left up to developer to decide.
 
 *** {Commit Message Template}
 
diff --git a/content/markdown/project-roles.md b/content/markdown/project-roles.md
index 7ee4f311..5926d18f 100644
--- a/content/markdown/project-roles.md
+++ b/content/markdown/project-roles.md
@@ -134,11 +134,25 @@ These are those people who have been given write access to the
 Apache Maven code repository and have a signed 
 [Contributor License Agreement (CLA)][4] on file with the ASF.
 
-The Apache Maven project uses a Commit then Review policy and has
-[a number of conventions][5] which should be followed.
+Committers are responsible for ensuring that every file they
+commit is covered by a valid CLA.
 
-Committers are responsible for ensuring that every file they 
-commit is covered by a valid CLA. 
+The Apache Maven project follows both ASF commit policies as described in
+[ASF Development Process](https://www.apache.org/foundation/how-it-works/legal.html)
+document.
+
+In general, "review then commit" (RTC) is required for complex changes or against "stable" 
+branches, while "commit then review" (CTR) is allowed for the rest of changes. 
+Always inform yourself (ultimately by asking on developers mailing list) which branches 
+are considered as "stable" and which as not stable ones.
+
+Naturally, while committers have write access to code repository, nothing prevents
+them to use personal forks of project repositories, hence creating pull requests
+may happen in both ways (as both has pros and cons): from branch in project 
+repository or from personal fork as well. It is left to developer how
+he organizes his own work.
+
+Committers should also follow [a number of conventions][5].
 
 Committers who would like to become PMC members should try to find
 ways to demonstrate the responsibilities listed in the PMC Members