Exherbo uses git for source code management (SCM). Some of the guidelines outlined in this document are based upon Documentation/SubmittingPatches, as part of git.git
When submitting a new package, first consider whether it’s really important enough to be in the official repositories, or whether you should instead put it in your own supplemental repository. If the quality of your supplemental repository is reasonably high, host it somewhere, and we’ll consider adding it to the unavailable-unofficial repository.
Do submit original work. Don’t blindly copy ebuilds, adjusting for differences between ebuilds and exhereses. If you need to install a package, there is a tool far more suitable that you can use instead of blindly adapting ebuilds to exheres.
Sometimes patching upstream sources is unavoidable. If you do apply patches, make sure they’re properly documented according to our patches policy, found in exheres-for-smarties. Always consider that adding patches that will not be accepted upstream means you get to maintain those.
To be included in any of our repositories, contributions must be licenced under the GPL-2. Add an appropriate copyright notice if your contributions to a given file warrant it. See exheres-for-smarties.
Patches can be contributed via our bugzilla, or in our IRC channel #exherbo. Commiting Patches in the IRC-Channel is favoured, the procedure is described on /dev/otaku.
All our documentation is written in markdown format and uses Maruku for HTML conversion.
We use the Creative Commons Attribution Share Alike 3.0 license for all documentation and website content. Contributions using other licenses are unlikely to be accepted.
Patches can be contributed via our bugzilla, or in our IRC channel #exherbo.
Configure your git author name and email properly. Use your real name. See man git-config, look for user.name and user.email.
Generate your patches using git format-patch, from local commits. If your patch renames files, please use the options -M -C to git format-patch, to detect copies and renames. This makes the resulting patch much easier to read. Alternatively, you can enable -M -C by default by running git config --global diff.renames copy. See man
git-format-patch.
Use a clear and descriptive commit message, explaining the change.
Write a short one line summary, followed by an empty line, and, as you see fit, a more elaborate description of your changes
Version bump is not an acceptable commit message. You should at least mention the package and version you’re adding. Try running git log --oneline on a repository full of Version bump commits and you’ll understand why.
In case your making non-obvious changes, consider explaining the reasoning behind the changes.
Do make references to relevant bug reports, mailing lists, … where appropriate.
Exhereses use 4 spaces and strictly no tabs for indentation. Run your patch through git diff
--check, to verify that it doesn’t introduce whitespace errors.
app-vim/exheres-syntax and app-emacs/exheres-mode will highlight common exheres syntax errors. Use them.
Copyright 2009 Ingmar Vanhassel
This work is licensed under the Creative Commons Attribution Share Alike 3.0 License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/3.0/; or, (b) send a letter to Creative Commons, 171 2nd Street, Suite 300, San Francisco, California, 94105, USA.