[Releasing] [Development] Change file process & improvement proposal
Kai.Koehne at qt.io
Thu Jan 26 13:28:30 CET 2017
> -----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
More information about the Releasing