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
Received on 2017-12-04 15:15:47 CET