From e37cb31107a33a720758e3265801e9367332ec33 Mon Sep 17 00:00:00 2001 From: Mroik Date: Tue, 31 Mar 2026 19:07:15 +0200 Subject: Initial commit A mailing list implementation by POuL for POuL that aims to be minimal but use SMTP to deliver receiving emails instead of LMTP. This is because mailing list software that use LMTP as their delivery mechanism make achieving modularized container environments harder. This is due to the fact that mailing lists that use LMTP require it and the main MTA to live on the same machine. This implementation aims to be good enough to be used as the mailing list for POuL in its kubernetes infrastructure (and frankly, it was about time that someone implemented a mailing list that could be "standalone" in containers). Signed-off-by: Mroik --- README.md | 41 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+) create mode 100644 README.md (limited to 'README.md') diff --git a/README.md b/README.md new file mode 100644 index 0000000..e4b8bdd --- /dev/null +++ b/README.md @@ -0,0 +1,41 @@ +# POuL-list +A mailing list by [POuL](https://poul.org/) (currently maintained by +[Mroik](https://gitlab.poul.org/mroik)). + +## Codestyle +So long as it passes `cargo fmt --check` it is fine. + +## Commit messages +When writing a commit message you may choose whatever style you prefer for the +subject line. The important thing is that the subject line is followed by one +or more paragraphs explaining the reasoning behind the change (this can be +omitted for trivial stuff at the discretion of the maintainer). + +## Contribution process +Development happens mainly on https://gitlab.poul.org/ +If you're not a POuL member you can send patches directly to the maintainer +(you can check the commit history for the email). + +Here's how a contribution cycle should go: +1. A review process starts only after an MR is open and marked as ready +2. There will be the usual discussion on the issues with the MR and suggestions + on how to fix it. +3. A new iteration will be sent by the author. Improvements should not be built + on top of the existing commits (unless making new ones make sense of + course), instead the author is expected to amend the commits with the + changes required. This keeps the history clean for those who'll come after. + * Anyone is welcome to review (it is encouraged) + * If the reviewer is not the maintainer then the reviewer will be given + recognition through the `Reviewed-by` trailer. This is not only to give + recognition, but it also has an additional `blame` functionality. +4. Points (2) and (3) are repeated until the MR reaches a satisfactory state +5. Before the commits are merged the maintainer will amend the commits by + adding their own signoff (as proof of acknowledgment) +6. The MR is merged + +## Signoff +All commits should be signed-off. A sign off in this project certifies your +work under the [DCO](https://developercertificate.org/). + +By signing off you also declare that you understand and will adhere to the +contribution process. -- cgit v1.3