This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]


On 11/12/18 13:28 +0100, Jakub Jelinek wrote:
On Tue, Dec 11, 2018 at 05:30:48PM +0530, Umesh Kalappa wrote:
Hi All,

Please find the attached patch for the subjected issue .

Do please let me know your thoughts and comments on the same .

Not a patch review (will defer that to rs6000 maintainers), but
some comments on gcc-patches patch submissions.

The subject should ideally start with [PATCH] or similar,
then have some short summary of what the patch is about and if
it fixes some PR, just PR something/12345 reference,
the subjects you are posting like:
don't say anything relevant except for the PR 84762 number,
so anyone reading gcc-patches needs to open that bug in order to even find
out if it is something for him or somebody else.

If you are sending a patch for an area that has some maintainer(s),
usually you should either mention those maintainers in To: (and CC:
gcc-patches) or To: gcc-patches, CC: the maintainers, to draw their
attention.  See MAINTAINERS file in GCC tree.

The mail body should start with a short explanation of what the problem is
and how are you solving it, again, so that people don't have to jump to
bugzilla to find out (of course, short is enough, no need to duplicate
dozens of comments from the PR), should include information on what
target(s) it has been bootstrapped/regtested.  And, it is always better if
it is the patch author that posts it, or is at least CCed so that he can
answer review questions.

Also, as noted at the
ChangeLog entry should be in plain text, not part of the patch.

"The ChangeLog entries should be plaintext rather than part of the
patch since the top of the ChangeLog changes rapidly and a patch to
the ChangeLog would probably no longer apply by the time your patch is

Some people add it as a second attachment, e.g.
or just inline in the email body, e.g.
Either is better than including the ChangeLog entry as part of the
patch itself.

Following the policies
will make it much more likely that patches will be seen by the right
people and reviewed.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]