On Mon, 15 Oct 2012, Gary Funck wrote: > Regarding ChangeLog entries, I can add them to each > change set, if that is needed. However, I was hoping to > wait on that until the patches are generally approved, > in principle.
As a patch submitter, it's your responsibility to make it easy for reviewers to review your patch. The ChangeLogs provide a roadmap for the patch - showing what is changed where, at a glance. They go alongside the plain text rationale, explaining at a higher level the structure and rationale for the changes and anything that might seem unclear as to why the patches work in a particular way. Each patch submission's Subject: line should best include a brief description of that patch as well, not just a patch number. Any changes that are not immediately and obviously inherently UPC-specific deserve specific explanation in the plain text rationale. That certainly includes such things as the langhook change I mentioned, the target changes and the changes to non-C-family front-end Make-lang.in files. In the case of the target changes, there should be a high-level explanation of how other target maintainers might determine whether changes to their targets might be appropriate for UPC, or how you determined that only those targets should be changed. For changes developed over several years, reading through them in detail to prepare a ChangeLog is particularly valuable as it will show up places where there are spurious changes (such as those to whitespace) that may have resulted from code being changed and changed again in the course of development, but that are not needed for a clean patch submission. I don't really think your division into 16 patches is a particularly good one - it separates things that should be together, and joins things that might better be separate. Putting documentation in a separate patch from the things documented is always bad, for example - if you have new target hooks, put the .texi changes in the same patch that adds those hooks. A better division might be: * Target changes, split out per target. * Changes to existing C front-end files (including c-family). * Changes to any other front ends, split out by front end. * New front-end files. * Changes to the language and target independent compiler (including build system code). * Library. * Compiler testsuite. -- Joseph S. Myers jos...@codesourcery.com
