This is the mail archive of the
mailing list for the binutils project.
Re: RISC-V Fixes for 2.28 v2
- From: Alan Modra <amodra at gmail dot com>
- To: Palmer Dabbelt <palmer at dabbelt dot com>
- Cc: binutils at sourceware dot org, vapier at gentoo dot org, Andrew Waterman <andrew at sifive dot com>
- Date: Mon, 19 Dec 2016 10:56:26 +1030
- Subject: Re: RISC-V Fixes for 2.28 v2
- Authentication-results: sourceware.org; auth=none
- References: <mhng-fbd27d11-738e-4eb9-aca6-679f3d8e5dab@palmer-mbp2014> <email@example.com>
On Sat, Dec 17, 2016 at 11:00:00PM -0800, Palmer Dabbelt wrote:
> Here's something that I hope is actually a set of ChangeLog entries this time,
I think that if you had read the link I gave you, you'd know that you
have not complied with ChangeLog requirements. So, no, this patchset
is not ready to commit. And yes, writing ChangeLogs is tedious.
Some tips: Create the ChangeLog at the same time as you edit the
source. Emacs "C-x 4 a" will usually give you a good entry and
mention the function being edited, which was one of the reasons why
your entries fail to be OK. Put the body of the ChangeLog entry in
the git log, along with a prototype email that will form the basis of
your eventual mailing list post. That way there isn't much work left
to do later, and leaving some sort of description in the git log is a
really good idea. Also, this keeps the ChangeLog entry with the patch
rather than putting it in the email covering letter. Do mention all
substantive changes in the ChangeLog, eg. you missed a mention of
fixing src_mask in the howtos. For non-substantive changes it's OK to
* filename.c: Formatting and comment fixes throughout.
and it's OK when making a change to a function signature to write
* filename.c (some_func): Add blah parameter, use to decide
blahness. Update all callers.
ie. you don't need to call out secondary details in perhaps dozens of
functions that need tweaking to pass an extra param to "some_func".
to help merge your local ChangeLog entries.
Australia Development Lab, IBM