On Mon, May 27, 2013 at 7:14 PM, Robert Newson <[email protected]> wrote: > If people want more than the one line summary, they can get the full > details from the commit message, so I'm not keen on doing extra work > (and commits) to generate redundant information. I'm -1 on adding the > section and jira information into the summary. It's already quite > short and these two items use precious characters. Since they can both > be put in the commit message later, it seems unnecessary to put them > in the summary (what's a summary if it contains every detail of the > commit? :)).
I think the bug identifiers in particular are pretty useful for developers, and about 5 characters isn't that much (just omit the silly COUCHDB- prefix). The section may not always make sense, but I think it's useful communication (e.g. most of you can happily ignore commit email where the commit message starts with "docs:"). > A big part of the motivation here is to avoid any release-time effort > in generating a change log at all since this is administrivia that can > delay releases. The idea being to do it piecemeal as we develop the > software. I'm interested if anyone would find it valuable to include > more than we've included in NEWS/CHANGES to date (and, more > importantly, if those people are prepared to do the work). I understand that, and I think better commit messages would go a long way here. I personally think the change log should still be edited by hand, and I'm happy to spend some time each month doing that. Though it should be in the nice documentation, not in NEWS/CHANGES. > A final point, I'm not sure the subsystem breakdown from CHANGES is > all that useful. It's certainly extra work for the author but does > that translate into a benefit for the user? Does anyone need to be > told that "Tolerate missing source and target fields in _replicator > docs" applies to the Replicator subsystem or that "Fix bug in WARN > level logging from 1.3.0" applies to the logging subsystem? It's > clearly redundant to me, and a burden to us. In my opinion someone > needs to make a strong case for continuing with that scheme, rather > than the inverse. I agree that the subsystems as currently used in CHANGES (and the change log) isn't that useful. That doesn't mean that there isn't some classification scheme that *does* make sense, of course (e.g. API vs. internals vs. configuration?). Cheers, Dirkjan
