Stefan Sperling wrote:
Johan Corveleyn wrote:
The intention is that the RM doesn't need to go through all the full
log messages in detail, but that he can trust the output of
write-changelog, combined with trust in the quality of the log
messages involved.
OK, in that light it all makes sense and I agree this is worth a try.
And if we don't manage to pull it off well enough, nothing is lost
compared to the status quo.
Johan, you told us at the hackathon (and mentioned in the older linked
thread) that your team has been using a system like this for some time
at your workplace. For me, that gives the suggestion a lot more credibility.
The 'contribulyzer' syntax we use in log messages is the same sort of
scheme. I am slightly surprised it was as successful and long-lasting as
it is. When it was introduced I think a lot of gentle reminders were
issued until most people got accustomed to writing it.
I like the idea of something that encourages us to put more user-facing
descriptions in log messages, for changes that have a user-facing
impact. Sometimes I check the change messages for system security
updates I am installing, and I notice the huge difference between those
that say "change sys.foo.bar back to 18 to fix #4321" and those that say
"disable auto-switching the wifi channel because it wasn't reliable
(#4321)".
In the case where a user-facing but very simple change is made, I think
we would only need to write the tagged user-facing line in the log
message -- we should never need to write two lines that say the same
thing. Example log message:
[[[
* subversion/svn/svn.c:
[U:client] Add a 'reintegrate merge' section to the 'svn help merge'.
]]]
I think one of the keys to making this successful is to keep the burden
low. For example, if "[U:section]" is the general tag for a user-visible
change then just "[U]" should be allowed so the dev can go ahead with
the commit when a suitable section is not defined or not obvious.
- Julian
