diff options
Diffstat (limited to 'polly/lib/External/isl/doc/SubmittingPatches')
| -rw-r--r-- | polly/lib/External/isl/doc/SubmittingPatches | 52 |
1 files changed, 52 insertions, 0 deletions
diff --git a/polly/lib/External/isl/doc/SubmittingPatches b/polly/lib/External/isl/doc/SubmittingPatches new file mode 100644 index 00000000000..2c2b93881bc --- /dev/null +++ b/polly/lib/External/isl/doc/SubmittingPatches @@ -0,0 +1,52 @@ +[Mostly copied from git's SubmittingPatches] + + Commits: + + - make commits of logical units + - check for unnecessary whitespace with "git diff --check" + before committing + - do not check in commented out code or unneeded files + - the first line of the commit message should be a short + description and should skip the full stop + - the body should provide a meaningful commit message, which + includes motivation for the change, and contrasts + its implementation with previous behaviour + - if you want your work included in isl.git, add a + "Signed-off-by: Your Name <you@example.com>" line to the + commit message (or just use the option "-s" when + committing) to confirm that you agree to the Developer's + Certificate of Origin + - make sure that you have tests for the bug you are fixing + - make sure that the test suite passes after your commit + + Patch: + + - use "git format-patch -M" to create the patch + - do not PGP sign your patch + - send a single patch per mail, e.g., using git-send-email(1) + - do not attach your patch, but read in the mail + body, unless you cannot teach your mailer to + leave the formatting of the patch alone. + - be careful doing cut & paste into your mailer, not to + corrupt whitespaces. + - provide additional information (which is unsuitable for + the commit message) between the "---" and the diffstat + - if you change, add, or remove a command line option or + make some other user interface change, the associated + documentation should be updated as well. + - if your name is not writable in ASCII, make sure that + you send off a message in the correct encoding. + - send the patch to the development mailing list + (isl-development@googlegroups.com). If you use + git-send-email(1), please test it first by sending email + to yourself. + + Revisions: + + - add the revision number inside square brackets to + the subject line (e.g., use --subject-prefix='PATCH v2' + when creating the patch) + - recall the major issues discovered during the previous + review and explain how you addressed them or why you + disagree. Do so either in a cover letter, between the + "---" and the diffstat or in a separate message. |
