From b988b06146c5d16e0ca0ea86ffcf2d83938088ed Mon Sep 17 00:00:00 2001 From: Phil Pennock Date: Sun, 25 Feb 2018 02:51:22 -0500 Subject: meta: git controls for text changelogs; github controls For the ChangeLog and files like it, use `merge=union` to bring in content from both sides instead of having conflicts block merges because someone else added a feature. For GitHub, provide some "templates" which really just point people in the right direction, but if the repointing fails, at least reduces the pain a little. --- .gitattributes | 7 +++++++ .github/ISSUE_TEMPLATE.md | 41 ++++++++++++++++++++++++++++++++++++++++ .github/PULL_REQUEST_TEMPLATE.md | 41 ++++++++++++++++++++++++++++++++++++++++ 3 files changed, 89 insertions(+) create mode 100644 .gitattributes create mode 100644 .github/ISSUE_TEMPLATE.md create mode 100644 .github/PULL_REQUEST_TEMPLATE.md diff --git a/.gitattributes b/.gitattributes new file mode 100644 index 000000000..30567178e --- /dev/null +++ b/.gitattributes @@ -0,0 +1,7 @@ +# Using merge=union should make it easier to maintain changelogs across +# branches, by using the text from both sides for the merge. +# +doc/doc-txt/NewStuff merge=union +doc/doc-txt/ChangeLog merge=union +doc/doc-txt/OptionLists.txt merge=union +src/README.UPDATING merge=union diff --git a/.github/ISSUE_TEMPLATE.md b/.github/ISSUE_TEMPLATE.md new file mode 100644 index 000000000..2a9348e2b --- /dev/null +++ b/.github/ISSUE_TEMPLATE.md @@ -0,0 +1,41 @@ +# The Exim Project does not use GitHub Issues + +Hey, we want your input, but we want to make sure that we actually see it and +that your help is not wasted, so please read this. + +The GitHub repo exists for convenience for some folks, and to host our Wiki. +The Git repo is an automated clone of our real repo over at +. + +Sometimes a maintainer will take a look at GitHub issues, just because we care +about the software and want to know about issues, but expect long delays. +It's not a really supported workflow. + +If you need help with configuration, or _think_ you've found a bug, then the +Exim Users mailing-list is the place to start. Many experienced postmasters +hang out there: + +Our documentation is _very_ extensive and if the behavior does not match the +documentation, then that's a bug to be reported. + +In addition, if using Debian or a derivative (such as *Ubuntu*), then you +should read: + +If you're absolutely sure it's a bug, and it's not a security problem, then +our Bugzilla is the main place to go: + +If you've found a security bug, then please email . +All Exim Maintainers can and do use PGP. +Keyring: +We don't have a re-encrypting mailer, just encrypt to all of them please. + + +## If you MUST file an issue on GitHub + +Read "How to Report Bugs Effectively": + + +Please include the OS details, output of `exim -d -bV 2>/dev/null` +and as much information as you think is relevant. + +Thanks. diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md new file mode 100644 index 000000000..8fa5a40df --- /dev/null +++ b/.github/PULL_REQUEST_TEMPLATE.md @@ -0,0 +1,41 @@ +# The Exim Project does not use GitHub Issues + +Hey, we want your input, but we want to make sure that we actually see it and +that your help is not wasted, so please read this. + +The GitHub repo exists for convenience for some folks, and to host our Wiki. +The Git repo is an automated clone of our real repo over at +. + +Sometimes a maintainer will take a look at GitHub pull requests, just because +we care about the software and want to know about issues, but expect long +delays. It's not a really supported workflow. + +Our bug-tracker takes code-patches and is the place to go: + + +If you've found a security bug, then please email . +All Exim Maintainers can and do use PGP. +Keyring: +We don't have a re-encrypting mailer, just encrypt to all of them please. + +## If this is too much hassle ... + +We do periodically get around to checking GitHub Pull Requests. +It just won't be fast. + +Patches should update the documentation, `doc/doc-docbook/spec.xfpt`; if you +like, just provide the plaintext which should go in there and we can mark it +up. + +If it's a whole new feature, then please guard it with a build +option `EXPERIMENTAL_FOO`; docs are in plaintext in +`doc/doc-txt/experimental-spec.txt`. + +If you're feeling particularly thorough, these files get updated too: +* `doc/doc-txt/ChangeLog` : all changes; workflow pre-dates Git +* `doc/doc-txt/NewStuff` : if it's a change in intended behavior which postmasters should read +* `doc/doc-txt/OptionLists.txt` : (we usually defer this until cutting a release) +* `src/README.UPDATING` : if you're breaking backwards compatibility + +Thanks! -- cgit v1.2.3