[Releasing] [Development] Change file process & improvement proposal
frederik.gladhorn at qt.io
Tue Jan 24 13:20:35 CET 2017
On tirsdag 24. januar 2017 12.00.40 CET Kai Koehne wrote:
> 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
> 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):
> > https://bugreports.qt.io/browse/QTQAINFRA-933
> 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)
Why only there? All relevant changes should have it - regardless of branch.
I would actually suggest we change the sanity bot to -1 any change that has no
[ChangeLog] entry. And we then agree on a marker that says "no changelog
At this point we'll be all constantly reminded to add change log entries and
it's still reasonably easy to opt out.
> (who could do this?)
> Releasing mailing list
> Releasing at qt-project.org
More information about the Releasing