commit: e567fc6f7d05d509bdac865606271f0bc2e132d6
Author: Michał Górny gentoo org>
AuthorDate: Sat Oct 14 18:14:40 2017 +
Commit: Göktürk Yüksek gentoo org>
CommitDate: Wed Jan 3 04:31:48 2018 +
URL:https://gitweb.gentoo.org/proj/devmanual.git/commit/?id=e567fc6f
Move the commit policy & commit message to git
ebuild-maintenance/git/text.xml | 158 ++
ebuild-maintenance/maintenance-tasks/text.xml | 151
2 files changed, 158 insertions(+), 151 deletions(-)
diff --git a/ebuild-maintenance/git/text.xml b/ebuild-maintenance/git/text.xml
index 2070217..59f1833 100644
--- a/ebuild-maintenance/git/text.xml
+++ b/ebuild-maintenance/git/text.xml
@@ -107,6 +107,164 @@ the historical commits after the initial git commit.
+
+Committing to gentoo.git
+
+
+
+Git Commit Policy
+
+
+
+Always run repoman scan before you commit.
+Please run repoman full before you commit.
+Always test that package.mask is okay by doing
+emerge --pretend mypkg before you commit and check
+that it doesn't contain any conflicts.
+Always commit the updated package.mask before
+the updated package.
+Always do atomic commits; if you commit a package with a new license,
+or that is masked, then first commit the revised package.mask
and/or license,
+then commit the ebuild, patches
+and metadata.xml all in
one go
+.
+ Although the set of changes in a single git commit is atomic, and
+combining package.mask/license changes with ebuild changes in a
+single commit wouldn't break atomicity, it is not currently possible to do so
+using repoman commit.
+
+
+
+
+
+
+
+Git Commit Message Format
+
+
+
+It is important to format the commit messages properly so that they
+communicate the changes to the reader in a clear and concise
+way. Additionally, consistency in message format allows for easier
+parsing by external tools. The first line of the commit message should
+contain a brief summary of the changes, followed by an empty new
+line. From the third line onward should be a detailed, multiline
+explanation of the changes introduced by the commit. At the very end,
+auxiliary information such as the bugs related to the commit,
+contributors, and reviewers should be listed using RFC822/git style
+tags. The length of the lines in the message should be 70-75
+characters at maximum.
+
+
+
+The summary line should start with referencing what is affected by the
+change followed by a colon ':' character. Use the rules in the
+following list to determine the proper format based on what has
+changed, substituting the package, category and eclass names
+appropriately:
+
+
+${CATEGORY}/${PN}:Single Package (Note that repoman commit
+automatically inserts this for you)
+${CATEGORY}: Package Category
+profiles: Profile Directory
+${ECLASS}.eclass: Eclass Directotry
+licenses: Licenses Directory
+metadata: Metadata Directory
+
+
+For packages where ${CATEGORY}/${PN}: is long, the line length
+limit can be exceeded, if absolutely necessary, to ensure a more
+useful summary line. If a commit affects multiple directories, prepend
+the message with which reflects the intention of the change best. If
+there are any bugs on Gentoo Bugzilla associated with the commit, id
+of the bug can be appended to the summary line using the format
+#BUG-ID. If you are modifying keywords, clearly state what
+keywords are added/removed.
+
+
+By default, lines starting with # are considered to be comments
+by git and not included in the commit message. Make sure that a new
+line does not start with #BUG-ID. Optionally, git can be
+configured to use a different character for comments by changing the
+commentchar option.
+
+
+
+
+For non-trivial commits, the message should contain a detailed
+explanation of what the commit intends to change, why it is required,
+and how it is accomplished, along with any other supplementary
+information.
+
+
+
+Finally the commit message should list auxiliary information such as
+people who are involved in authoring, suggesting, reviewing and
+testing the changes, and revelant bugs. Use RFC822/git style tags as
+explained in the
+https://kernel.org/doc/html/latest/process/submitting-patches.html";>
+Linux Kernel patch guideline. Additionally, the following tags
+are optionally used in Gentoo:
+
+
+Bug: Use this to reference bugs without closing them.
+The value is a URL to the bug. If multiple bugs need to be referenced,
+each one should be listed in a separate Bug tag. If a bug
+on Gentoo Bugzilla, or an issue or a pull request on GitHub
+is referenced, a reference to the commit will be added
+automatically.
+Closes: Use this to reference bugs and close them
+automatically. Alike Bug:, the value is a single URL to the bug,
+and multiple tags can be used to close multiple bugs. If a bug on Gentoo
+Bugzilla, or an issue or a pull request on a GitHub repository
+mirrored by Gentoo is referenced, it will be closed (as fixed)
+automatically with reference to the
