Prepare for publishing

* COMMIT-LOG-GUIDELINES: New file.
	* CONTRIBUTING: New file.
	* README: Amended to refer to the first files above.
This commit is contained in:
Dodji Seketeli 2013-07-16 22:32:34 +02:00
parent 7daf60f12c
commit 921f0d36ea
3 changed files with 107 additions and 0 deletions

48
COMMIT-LOG-GUIDELINES Normal file
View File

@ -0,0 +1,48 @@
Git commit messages format
==========================
The principle of the git commit log is to document at least the
*what*; in English. That is redundant with the commit diff, yes. But
that redundancy does help in understanding the commit diff better. If
appropriate, the commit log can also document the *why*, but only if
it does so by respecting the format of the commit log. The reason why
we are so strict about the format is that the commit log is later
parsed by a tool to build a ChangeLog, which we want to stay compliant
with the GNU ChangeLog format.
So here is the format we are talking about.
The first line of a git commit message should start at column 1, with
no space. That line should be a short summary of the purpose of the
commit. If the commit relates to a bug filed into bugzilla, the line
should begin with the bug (or Problem Report) number, followed by a
white space; e.g:
PR <number-of-the-bug> This is a great commit
The line in its entirety should not be longer than 50 characters.
The next line should be an empty line, with no spaces.
The subsequent lines should have the form of the Body of a GNU ChangeLog
entry, i.e:
* file1.c (func1): Changed foo in this function.
(func2): Changed blah in that function
* file2.c (func_foo): Changed something here.
Note that before the '*', there is a tab that is 8 spaces long. Also
note that right after the '*', there is a space.
An exemple of commit message would be:
~=~
PR 123456 Shorten compilation lines
* configure.ac: Shorten compilation lines by regrouping
PKG_CHECK_MODULES calls.
* tests/Makefile.am: Adjust this.
~=~
We encourage you to look at the existing commit logs or at the
ChangeLog file for inspiration.

53
CONTRIBUTING Normal file
View File

@ -0,0 +1,53 @@
The project homepage is at https://sourceware.org/libabigail
The current libabigail source code can be checked out with:
git clone git://git.sourceware.org/git/libabigail
The mailing list to send messages and patches to is
libabigail@sourceware.org.
The archives of that list are available at http://sourceware.org/ml/libabigail.
Please supply patches using git format-patch or using git send-email.
Bugs are to be filled in bugzilla at http://sourceware.org/bugzilla.
Sign your work
To facilitate tracking of who did what, we've adopted a "sign-off"
procedure for patches based on the procedure used by the Linux kernel
project.
The sign-off is a simple line at the end of the explanation for the
patch, which certifies that you wrote it or otherwise have the right
to pass it on as a patch under an appropriate license. The rules are
pretty simple: if you can certify the below:
Developer's Certificate of Origin
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me,
and I have the right to submit the contribution under the
license indicated in, or otherwise designated as being
applicable to, the file.
(b) The contribution was provided directly to me by some other
person who certified (a), and I have not modified it.
(c) I understand and agree that the project and the
contribution are public and that a record of the
contribution (including all personal information I submit
with it, including my sign-off) is maintained indefinitely
and may be redistributed.
then you just add a line saying
Signed-off-by: Random J Developer <random@developer.example.org>
using your real name (sorry, no pseudonyms or anonymous contributions.)
git commit --signoff will add such a Signed-off-by line by at the end of
the commit log message for you.
Happy Hacking!

6
README
View File

@ -14,3 +14,9 @@ two ABI Corpuses, provide detailed information about their
differences, and help build tools to infer interesting conclusions
about these differences.
You are welcome to contribute to this project after reading the files
CONTRIBUTING and COMMIT-LOG-GUIDELINES files in the source tree.
Communicating with the maintainers of this project -- including
sending patches to be include to the source code -- happens via email
at libabigail@sourceware.org.