[Releasing] [Development] Change file process & improvement proposal
Spencer.Schumann at echostar.com
Thu Jan 26 17:11:09 CET 2017
> For the sanity bot, either we decide that _every_ change has a [ChangeLog], or we try to make the bot intelligent
> enough to decide whether a commit needs a change log, or not. Parts of the discussion so far makes me think
> that this will be an uphill battle though.
> So, any strong opinion against enforcing a [ChangeLog] line, with "[ChangeLog] -" for commits that don't need one?
I doubt the decision on whether a changelog is needed could be adequately automated. Sometimes, even a one character change might need a detailed changelog.
Isn't this something that could and should be enforced via the code review process? If reviewers see that the changelog is missing or inadequate, they can reject the change.
From: Releasing <releasing-bounces+spencer.schumann=echostar.com at qt-project.org> on behalf of Kai Koehne <Kai.Koehne at qt.io>
Sent: Thursday, January 26, 2017 5:28:30 AM
To: Oswald Buddenhagen; development at qt-project.org; releasing at qt-project.org
Subject: Re: [Releasing] [Development] Change file process & improvement proposal
> -----Original Message-----
> From: Releasing [mailto:releasing-bounces+kai.koehne=qt.io at qt-
> project.org] On Behalf Of Oswald Buddenhagen
> Sent: Thursday, January 26, 2017 12:52 PM
> To: development at qt-project.org; releasing at qt-project.org
> Subject: Re: [Releasing] [Development] Change file process & improvement
> On Thu, Jan 26, 2017 at 09:51:24AM +0100, Edward Welbourne wrote:
> > I don't know what you're saying, much less why it's supposed to be the
> > obvious interpretation. A "tagged commit" is presumably v5.7.0 or
> > similar; why should a commit without an amends line be assumed to
> > relate to one of these ?
> i used "tagged commit" as a shorthand for "a commit which is reachable from
> a tag", which should be fairly clear from the context. i.e., "git tag --contains
> <sha1>" returns something.
Well, I had a hard time deciphering this, too.
Anyway, this all feels like we get side-tracked in details. To reiterate:
- We do (still) have a problem with our ChangeLog files
* The quality of the entries, and the scope, greatly differs (between modules)
* We do have a problem getting them in place on time for a release
Jani's proposal is to fix parts of this is to encourage committers and reviewers to write [ChangeLog] entries as part of the commit. This could be encouraged by
* Enabling the [ChangeLog] line by default in the commit template
* Enforcing a [ChangeLog] entry by the Sanity Bot (under conditions xxx)
For the sanity bot, either we decide that _every_ change has a [ChangeLog], or we try to make the bot intelligent enough to decide whether a commit needs a change log, or not. Parts of the discussion so far makes me think that this will be an uphill battle though.
So, any strong opinion against enforcing a [ChangeLog] line, with "[ChangeLog] -" for commits that don't need one?
> Releasing mailing list
> Releasing at qt-project.org
Releasing mailing list
Releasing at qt-project.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Releasing