This is the mail archive of the
mailing list for the binutils project.
RISC-V Fixes for 2.28 v3
- From: Palmer Dabbelt <palmer at dabbelt dot com>
- To: amodra at gmail dot com
- To: binutils at sourceware dot org
- Cc: Andrew Waterman <andrew at sifive dot com>
- Date: Sun, 18 Dec 2016 20:27:02 -0800
- Subject: RISC-V Fixes for 2.28 v3
- Authentication-results: sourceware.org; auth=none
- References: <20161219002626.GA31638@bubble.grove.modra.org>
On Sun, 18 Dec 2016 16:26:26 PST (-0800), email@example.com wrote:
> 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.
Sorry, I guess I must have just gotten confused as to what the format was.
I've read the web page again (and read more of the ChangeLog entries in
binutils) and I think I have a proper ChangeLog now.
Sorry for the trouble!
> 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
> just write
> * 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.
Thanks for the tips. As suggested, I've put the ChangeLog entries into each
patch's git log, they will be sent along with each patch. I'll try to avoid
screwing this up again in the future.
Thanks for all the help!