Andy Piper <andyp(a)parallax.co.uk&gt; writes: ... The policy has been fairly lax. ChangeLog entries have been requested if missing, but in the case of small patches that I understand and can test, have not been an impediment to getting the patch applied. In the case of small & obvious (or documented elsewhere) patches, I've made the ChangeLog entries myself while applying the patch. In certain circumstances I'll apply ChangeLog-less medium-sized (or larger :-() patches and *not* add proper entries. This is evil -- I want this practice formally stopped. I don't have time to check every line of every patch that goes into XEmacs, but I don't think it's unreasonable to expect that people making patches use add-log.el as they go along. It's very easy to use and even its critics like Kyle, appear to have no problem synthetically generating ChangeLog entries. In other circumstances large patches have been accompanied by incomplete ChangeLog entries. I wish this practice stopped as well, hence this discussion. TopLevel ChangeLog: 1998-06-26 J Random Luser <luser(a)aol.com&gt; **/*: Global change to do blah is *not* a proper ChangeLog entry and does nothing to help maintainers figure out what has gone wrong if something gets broken. We *have* to consider maintainability as a top priority. I propose the following addition to the rules of approving patches on xemacs-review: If a ChangeLog-less patch appears that you wish to approve because it is in your area of expertise of XEmacs, you include appropriate ChangeLog entries with the approval. It solves everything, including recalcitrant developers who refuse to document their work.