1) We're all for including the JIRA ticket, for traceability, the question I have is why put that in the summary line?
2) There might be a classification scheme that makes sense but, since we agree the present one doesn't, can we ditch it until someone proposes a better one? B. On 28 May 2013 08:50, Dirkjan Ochtman <[email protected]> wrote: > 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
