couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <rnew...@apache.org>
Subject Re: [VOTE] Git Commit Messages
Date Tue, 28 May 2013 08:10:28 GMT
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 <dirkjan@ochtman.nl> wrote:
> 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