Avoid the long whats_supported line being mixed with output from other processes
[users/heiko/exim.git] / .github / PULL_REQUEST_TEMPLATE.md
1 # The Exim Project does not use GitHub Issues
2
3 Hey, we want your input, but we want to make sure that we actually see it and
4 that your help is not wasted, so please read this.
5
6 The GitHub repo exists for convenience for some folks, and to host our Wiki.
7 The Git repo is an automated clone of our real repo over at
8 <https://git.exim.org/exim.git>.
9
10 Sometimes a maintainer will take a look at GitHub pull requests, just because
11 we care about the software and want to know about issues, but expect long
12 delays.  It's not a really supported workflow.
13
14 Our bug-tracker takes code-patches and is the place to go:
15 <https://bugs.exim.org/>
16
17 If you've found a security bug, then please email <security@exim.org>.
18 All Exim Maintainers can and do use PGP.
19 Keyring: <https://ftp.exim.org/pub/exim/Exim-Maintainers-Keyring.asc>
20 We don't have a re-encrypting mailer, just encrypt to all of them please.
21
22 ## If this is too much hassle ...
23
24 We do periodically get around to checking GitHub Pull Requests.
25 It just won't be fast.
26
27 Patches should update the documentation, `doc/doc-docbook/spec.xfpt`; if you
28 like, just provide the plaintext which should go in there and we can mark it
29 up.
30
31 If it's a whole new feature, then please guard it with a build
32 option `EXPERIMENTAL_FOO`; docs are in plaintext in
33 `doc/doc-txt/experimental-spec.txt`.
34
35 If you're feeling particularly thorough, these files get updated too:
36 * `doc/doc-txt/ChangeLog` : all changes; workflow pre-dates Git
37 * `doc/doc-txt/NewStuff` : if it's a change in intended behavior which postmasters should read
38 * `doc/doc-txt/OptionLists.txt` : (we usually defer this until cutting a release)
39 * `src/README.UPDATING` : if you're breaking backwards compatibility
40
41 Thanks!