The mailserver is designed as a whole, some images are therefore not best suited for reuse outside this project. All images should however follow Docker best practices and be as generic as possible :
- even if not suited for reuse, they should be simple enough to fit as base images for other projects,
- interesting settings should be available as environment variables
- base images should be well-trusted (officiel Alpine or Debian for instance).
Forking vs. committing¶
Linus’ way of things sounds fine for now: if you find yourself implementing a new feature, either send me an email with a bunch of commits or use Github pull request feature. Maybe if the user base grows too much as well as the need for trust in a specific branch of the project, we can switch to a shared repository and add a couple of trusted committers.
This is a community project, thus commits should be readable enough for any of the contributors to guess the content by simply reading the comment or find a proper commit when one knows what he is looking for.
Usual standards remain: write english comments, single line short comments and additional multiline if required (keep in mind that the most important piece of information should fit in the first line).
You are of course free of naming you branches to your taste or even using master directly if you find this appropriate. Still, keep in mind that:
- a git email or a pull request should address a single feature a bug, so keep your branches as tidy as possible;
- this is a small project with a limited number of forks and active threads
on Github, so one might want to look at your fork and find the branch you
are using to implement a specific feature; to avoid any hassle, we suggest
that you use branch names prefixed with
fix-and followed either by the name of the Github issue or a short and meaningful name.
All commits will be merged to the main
master branch for testing. New
images are built by Docker Hub with the
testing tag for each new commit on
After some brief testing, urgent fixes will be cherry-picked to the current stable branch and new stable builds will be released.
At the end of every milestone, a new stable branch will be created from
or any previous commit that matches the completion of the milestone.
If you find yourself forking the project for a specific independant purpose (commercial use, different phylosophy or incompatible point of view), we would be glad if you let us know so that we can list interesting known forks and their specific features (and backport some of them if your implementation is free as well).