couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dirkjan Ochtman <dirk...@ochtman.nl>
Subject Re: [VOTE] Git Commit Messages
Date Tue, 28 May 2013 07:50:34 GMT
On Mon, May 27, 2013 at 7:14 PM, Robert Newson <rnewson@apache.org> 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

Mime
View raw message