You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

153 lines
4.3 KiB

Please read the following guidelines before contributing.
1. The basic unit of contribution is a "git commit". This will be merged into
master by one of the team members who will review it and sign-off/commit or
reject it. If the commit is in another branch, it will added to HEAD/master
git cherry-pick -s <tree-ish>
Or if the commit is submitted as a stand alone file produce by
git format-patch <tree-ish>
Then it will be committed by
git am -s 0001-foo-bar.patch
Or if the commit is submitted as a github merge request, then the github web
interface can be used.
2. Work in a branch immediately off of master, do not work directly in master,
and do not be afraid of creating a local branch for every experimental thing you
want to try:
git checkout master # make sure your on master
git branch idea1 # I've got an idea, let me work on it
git checkout idea1
<hack ... hack ... hack>
git commit -m "step1" # I like what I've done so far, but I'm not finished
<hack ... hack ... hack>
git commit -m "step2"
<hack ... hack ... hack>
git commit -m "step3"
<hack ... hack ... hack>
git revert <tree-ish for step2> # Wow step 2 was dumb
<hack ... hack ... hack>
git commit -m "step4" # Its good now, but those
# commits are messy
git rebase -i <tree-ish step1>^ # start a rebase on the parent of step1
(drop into editor and squash commits) # note the ^ at the end!
(exit editor and fix commit message)
Alternatively, you can cherry-pick those commits into another prestine branch:
... its good to go! ....
git checkout master
git branch idea1-clean
git checkout idea1-clean
git cherry-pick <sha1-of-good-commit1>
git cherry-pick <sha1-of-good-commit2>
(pick them in any order that stacks)
(you can skip commits, but do them in the correct order to avoid conflits)
git rebase -i <tree-ish of sha1-of-good-commit1>^ # squash many commits into one
# note the ^ at the end!
Once you are done with a local branch you can delete it using
git branch -D idea1
You can delete a remote branch by doing
git push origin :idea1
3. Your commit message should conform to the following standard:
file/changed: Concice and complete statement of the purpose
This is the body of the commit message. The line above is the
summary. The summary should be no more than 72 chars long. The
body can be more freely formatted, but make it look nice. Make
sure to reference any bug reports and other contributors. Make
sure the correct authorship appears. Reference any early commits
by their full shaw:
which you can put on its own line and indent.
X-Gentoo-Bug: 400837
Reported-by: Snoopy Coderdog <>
Signed-off-by: Anthony G. Basile <>
If you commit using
git commit -s
your sign-off will be automatically added. If the authorship is wrong
fix it by
git commit -s --author="Richard Feynmann <>"
If the message doesn't look right after you commit locally, you can fix it by
git commit --amend.
Then push it to your public repo.
4.a Open an issue at (using GitHub)
And request a pull of your clean commit. A team member will review it,
discuss it and commit it to master or reject it.
4.b Send to mailing list (using git format-patch)
Make sure you are subscribe on the mailing list. If you do not, send an email to
and follow instructions.
When sending patches to mailing list, use
git send-email --to 0001-foo-bar.patch
5. eudev is a peer-reviewed project. So even team members must ask another
team member to sign-off and commit your work. The only exception are trivial
6. HEAD/master must always build and must always be considered stable.
7. Releases should be tagged and signed using
git tag -s -u <gpg name> -m "Release X"
where X is the full release number. Make sure that before you release,
you change the value in AC_INIT of to match the release
8. Tarball releases should be made from HEAD/master at signed tagged points
by doing
make dist
9. TODO: coding style for C, python, perl and autotool stuff.