[Releasing] [Development] Change file process & improvement proposal
Kai.Koehne at qt.io
Tue Jan 24 13:00:40 CET 2017
Looks like this discussion got stuck before reaching a conclusion ...
> -----Original Message-----
> From: Development [mailto:development-bounces+kai.koehne=qt.io at qt-
> project.org] On Behalf Of Oswald Buddenhagen
> Sent: Thursday, November 10, 2016 3:23 PM
> To: development at qt-project.org; releasing at qt-project.org
> Subject: Re: [Development] Change file process & improvement proposal
> > 1) Let's enable [ChangeLog] -tag by default in commit template. After
> > that you must remove/comment out it by purpose if you don't want add
> > it.
> i really don't think this will make a positive difference. the problem is that
> many people just don't have the right audience-oriented mindset.
> we *already* have lots of garbage changelog entries, and this will just
> worsen the S/N ratio.
Actually looking through the commit logs e.g. in qtbase, I do think most [ChangeLog] entries are rather fine - surely some tweaking is sometimes necessary, but the quality of the ChangeLog entries we have is not all that bad.
What is obvious though is that a lot of commits where I would have expected a [ChangeLog] do not have one. What's more, a well written [ChangeLog] entry will help also during the review, and can serve as a sanity check when it comes to the right branch being targeted etc.
I therefore agree with Janne that we should encourage people to write them, and changing the default template is a very easy thing to do.
> > And in addition to this update sanity bot so that it will give '-1' if
> > change log entry isn't given in release branch.
> this is probably not sensible. most last-minute fixes relate to recently
> introduced problems, which means that they specifically *don't* need
> changelog entries.
That might be the case until the first .0 release from the branch is done, but surely not afterwards.
Proposal: Check for [ChangeLog] entries in a 5.x branch _after 5.x.0 branched_. Is that easy to enable/disable?
> here's what i think would actually make a difference (based on historical
> evidence within trolltech):
Such a tool/infrastructure would be cool to have, indeed. It requires a lot more investment though than the incremental changes Jani proposed.
I therefore suggest to implement Jani's suggestions for the time being. If we find out they're not effective, we can always come back and look into alternative processes.
1. Enable [ChangeLog] tag in commit template
2. Add check in sanity bot to check for missing ChangeLog entries (potentially only in 5.x branches after 5.x.0 is out)
(who could do this?)
More information about the Releasing