[Development] [Releasing] Change file process & improvement proposal

[Mitch Curtis]

It seems that not every reviewer with approval rights is aware (or seems to care, or just forgets) about stuff like this, though. It's a similar problem with docs; no doc team member is added to patches and so you end up with lots of doc issues that they then have to stumble upon after years of it being exposed to the public.

From: Releasing [mailto:releasing-bounces+mitch.curtis=qt.io at qt-project.org] On Behalf Of Schumann, Spencer
Sent: Thursday, 26 January 2017 5:11 PM
To: Kai Koehne <Kai.Koehne at qt.io>; Oswald Buddenhagen <Oswald.Buddenhagen at qt.io>; development at qt-project.org; releasing at qt-project.org
Subject: Re: [Releasing] [Development] Change file process & improvement proposal


> 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.



- Spencer

________________________________
From: Releasing <releasing-bounces+spencer.schumann=echostar.com at qt-project.org<mailto:releasing-bounces+spencer.schumann=echostar.com at qt-project.org>> on behalf of Kai Koehne <Kai.Koehne at qt.io<mailto:Kai.Koehne at qt.io>>
Sent: Thursday, January 26, 2017 5:28:30 AM
To: Oswald Buddenhagen; development at qt-project.org<mailto:development at qt-project.org>; releasing at qt-project.org<mailto: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<mailto:releasing-bounces+kai.koehne=qt.io at qt-%0b%3e%20project.org>] On Behalf Of Oswald Buddenhagen
> Sent: Thursday, January 26, 2017 12:52 PM
> To: development at qt-project.org<mailto:development at qt-project.org>; releasing at qt-project.org<mailto:releasing at qt-project.org>
> Subject: Re: [Releasing] [Development] Change file process & improvement
> proposal
>
> 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?

Regards

Kai

> _______________________________________________
> Releasing mailing list
> Releasing at qt-project.org<mailto:Releasing at qt-project.org>
> http://lists.qt-project.org/mailman/listinfo/releasing
_______________________________________________
Releasing mailing list
Releasing at qt-project.org<mailto:Releasing at qt-project.org>
http://lists.qt-project.org/mailman/listinfo/releasing
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170127/0027c267/attachment.html>