On Wed, Jan 10, 2018 at 14:11:23 +0000, Joseph Myers wrote: >> Entities are concrete, >> unambiguous---you can phrase them only one way. > > For the example I gave of Makefile entity names involving complicated GNU > make constructs, that needed to be wrapped over multiple lines, that's not > the case. > > For cases where what's really changing is conditionals rather than > entities, there's significant ambiguity about how to write them in the > ChangeLog entry. [foo || bar] or [defined foo || defined bar]? Do you do > "* [foo]: Remove conditional code." or list the individual entities > removed within [foo]? If it's a makefile conditional, do you use [ifeq > ($(foo), bar)] or [$(foo) = bar]? > > Where the full name of an entity is long - with namespace or class > qualification, or requiring parameter types for an overloaded function - > exactly what form do you use?
That's a fair argument that's in some cases can be difficult to solve even with convention. But their existence/frequency depends on the type of project. If you look through the Emacs ChangeLogs, for example, Lisp entities are easy to convey. So I concede that the entity format of ChangeLogs aren't a one-size-fits-all type of thing. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com
signature.asc
Description: PGP signature