Re: [Development] Please add [ChangeLog] entries to your commits!

[Thiago Macieira]

On Wednesday, 31 May 2017 05:50:35 PDT Oswald Buddenhagen wrote:
> On Wed, May 31, 2017 at 02:38:53PM +0200, Robin Burchell wrote:
> > To me, it's implicit that each release will ideally have improvements in
> > terms of stability, so I think that there's less point in focusing on
> > them, unless they are a major newsworthy item: something like "sorry we
> > released 1.0.0 yesterday, but it turns out that feature foo was totally
> > broken, have 1.0.1 today to fix that" would be newsworthy, but "we fixed
> > a crash that has existed for the past 3 years" - less so, but that's my
> > own personal view.
> 
> the trolltech policy was to always add a changelog entry when there was a
> proper bug report. that seems reasonable, because there is (or at least
> was) somebody waiting for that fix.

Which is why, as a maintainer, I did a quick git log --grep=Task-number and 
checked which bug fixes did not have a changelog entry but should have had (not 
all needed it).

(I think there's a way to make git do the skipping, but I'd have to look at 
the manual)

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Please add [ChangeLog] entries to your commits!

[Mitch Curtis]

> -Original Message-
> From: Development [mailto:development-bounces+mitch.curtis=qt.io@qt-
> project.org] On Behalf Of Robin Burchell
> Sent: Wednesday, 31 May 2017 3:02 PM
> To: development@qt-project.org
> Subject: Re: [Development] Please add [ChangeLog] entries to your commits!
> 
> On Wed, May 31, 2017, at 02:50 PM, Oswald Buddenhagen wrote:
> > On Wed, May 31, 2017 at 02:38:53PM +0200, Robin Burchell wrote:
> > > To me, it's implicit that each release will ideally have
> > > improvements in terms of stability, so I think that there's less
> > > point in focusing on them, unless they are a major newsworthy item:
> > > something like "sorry we released 1.0.0 yesterday, but it turns out
> > > that feature foo was totally broken, have 1.0.1 today to fix that"
> > > would be newsworthy, but "we fixed a crash that has existed for the
> > > past 3 years" - less so, but that's my own personal view.
> > >
> > the trolltech policy was to always add a changelog entry when there
> > was a proper bug report. that seems reasonable, because there is (or
> > at least
> > was) somebody waiting for that fix.
> 
> Yes, however, if they are waiting for the fix, one would assume they are
> also subscribed to the bug tracker, and presumably watching the bug.
> They'll get a notification when the bug state changes (and a fix version
> is added). I should note that I'm not opposed to mentioning more stuff, I
> was just talking about my own editorial process when digging around after
> stuff missing changelog entries.

It's hard to beat the automatic notifications that Jira has. Anyone who has a 
business interest in a bug should be watching it in Jira.

I don't remember seeing ChangeLog entries for fixes for non-critical bugs, and 
I imagine it would be really hard to get people to do this, which is why I was 
suggesting (on #qt-labs, and I'm probably not the first) that it would be good 
to have a way to automatically add one based on the task number and the title 
of the bug report (either as a post commit hook or maybe some script that the 
changelog script calls to fetch the info from git log). For example, for 
https://bugreports.qt.io/browse/QTBUG-1000, it could be something like:

[ChangeLog][QTBUG-1000] Fixed "QTableWidget Row Remove/Insert bug"

The titles could of course be edited by the maintainer (either after the 
changelog has been generated, or they could be more conscientious about editing 
bad bug report titles), but for the most part the titles are fairly sane and 
wouldn't need changing.

> --
>   Robin Burchell
>   ro...@crimson.no
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Please add [ChangeLog] entries to your commits!

[Robin Burchell]

On Wed, May 31, 2017, at 02:50 PM, Oswald Buddenhagen wrote:
> On Wed, May 31, 2017 at 02:38:53PM +0200, Robin Burchell wrote:
> > To me, it's implicit that each release will ideally have improvements in
> > terms of stability, so I think that there's less point in focusing on
> > them, unless they are a major newsworthy item: something like "sorry we
> > released 1.0.0 yesterday, but it turns out that feature foo was totally
> > broken, have 1.0.1 today to fix that" would be newsworthy, but "we fixed
> > a crash that has existed for the past 3 years" - less so, but that's my
> > own personal view.
> > 
> the trolltech policy was to always add a changelog entry when there was a
> proper bug report. that seems reasonable, because there is (or at least
> was) somebody waiting for that fix.

Yes, however, if they are waiting for the fix, one would assume they are
also subscribed to the bug tracker, and presumably watching the bug.
They'll get a notification when the bug state changes (and a fix version
is added). I should note that I'm not opposed to mentioning more stuff,
I was just talking about my own editorial process when digging around
after stuff missing changelog entries.

-- 
  Robin Burchell
  ro...@crimson.no
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Please add [ChangeLog] entries to your commits!

[Oswald Buddenhagen]

On Wed, May 31, 2017 at 02:38:53PM +0200, Robin Burchell wrote:
> To me, it's implicit that each release will ideally have improvements in
> terms of stability, so I think that there's less point in focusing on
> them, unless they are a major newsworthy item: something like "sorry we
> released 1.0.0 yesterday, but it turns out that feature foo was totally
> broken, have 1.0.1 today to fix that" would be newsworthy, but "we fixed
> a crash that has existed for the past 3 years" - less so, but that's my
> own personal view.
> 
the trolltech policy was to always add a changelog entry when there was a
proper bug report. that seems reasonable, because there is (or at least
was) somebody waiting for that fix.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Please add [ChangeLog] entries to your commits!

[Robin Burchell]

My rule of thumb (when editing qtdeclarative's, for the last releases)
has been to include things depending on the "size" of the release. Small
(patch level) release? Include more bugs. Large (.0) release? Less focus
on bugs, more focus on architectural changes, feature additions, etc.
Any behavioral changes are always something that should be mentioned, of
course.

To me, it's implicit that each release will ideally have improvements in
terms of stability, so I think that there's less point in focusing on
them, unless they are a major newsworthy item: something like "sorry we
released 1.0.0 yesterday, but it turns out that feature foo was totally
broken, have 1.0.1 today to fix that" would be newsworthy, but "we fixed
a crash that has existed for the past 3 years" - less so, but that's my
own personal view.

-- 
  Robin Burchell
  ro...@crimson.no

On Wed, May 31, 2017, at 02:30 PM, Mitch Curtis wrote:
> > -Original Message-
> > From: Kai Koehne
> > Sent: Tuesday, 30 May 2017 9:31 AM
> > To: Mitch Curtis ; development@qt-project.org
> > Subject: RE: Please add [ChangeLog] entries to your commits!
> > 
> > 
> > 
> > > -Original Message-
> > > From: Mitch Curtis
> > > Sent: Monday, May 29, 2017 3:27 PM
> > > To: Kai Koehne ; development@qt-project.org
> > > Subject: RE: Please add [ChangeLog] entries to your commits!
> > >
> > > > [...]
> > > > Please be reminded that all changes that might be of interest to the
> > > > end user should be part of the ChangeLog.  So please, whenever
> > > > reviewing a change, please check whether a [ChangeLog] entry is in
> > order.
> > >
> > > Do we have a set of guidelines for what is considered interesting?
> > 
> > I'd say anything that changes observable behavior of existing features, or
> > new features.
> > 
> > Should get a [ChangeLog]
> > - new features
> > - fixes for bugs in released versions of Qt
> > 
> > Can be ignored:
> > - fixes in tests
> > - doc fixes
> > - pure code cleanup
> > - fixes for regressions introduced in not-yet-released commits
> > 
> > Regards
> > 
> > Kai
> > 
> > (who considers starting a QUIP about this ...)
> 
> There's also this one:
> 
> https://wiki.qt.io/Commit_Policy
> 
> That doesn't mention anything about change log entries for non-critical
> bug fixes.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Please add [ChangeLog] entries to your commits!

[Kai Koehne]

> -Original Message-
> From: Mitch Curtis
> Sent: Monday, May 29, 2017 3:27 PM
> To: Kai Koehne ; development@qt-project.org
> Subject: RE: Please add [ChangeLog] entries to your commits!
> 
> > [...]
> > Please be reminded that all changes that might be of interest to the
> > end user should be part of the ChangeLog.  So please, whenever
> > reviewing a change, please check whether a [ChangeLog] entry is in order.
> 
> Do we have a set of guidelines for what is considered interesting?

I'd say anything that changes observable behavior of existing features, or new 
features.

Should get a [ChangeLog]
- new features
- fixes for bugs in released versions of Qt

Can be ignored:
- fixes in tests
- doc fixes
- pure code cleanup
- fixes for regressions introduced in not-yet-released commits

Regards

Kai 

(who considers starting a QUIP about this ...)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Please add [ChangeLog] entries to your commits!

[Mitch Curtis]

> -Original Message-
> From: Development [mailto:development-bounces+mitch.curtis=qt.io@qt-
> project.org] On Behalf Of Kai Koehne
> Sent: Monday, 29 May 2017 12:43 PM
> To: development@qt-project.org
> Subject: [Development] Please add [ChangeLog] entries to your commits!
> 
> Hi,
> 
> I just noticed that, out of the 61 commits in qtbase/5.9 that are not part of
> 5.9.0, only one has a [ChangeLog] entry.
> 
> Some of the commits are either changes to doc, or autotests, but for the
> rest: If it is not important enough to be mentioned to the user, why is the
> change in 5.9?
> 
> Please be reminded that all changes that might be of interest to the end user
> should be part of the ChangeLog.  So please, whenever reviewing a change,
> please check whether a [ChangeLog] entry is in order.

Do we have a set of guidelines for what is considered interesting?

> Thanks
> 
> Kai
> 
> --
> Kai Köhne, Senior Manager R | The Qt Company
> 
> The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
> Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
> Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331
> B
> 
> The Future is Written with Qt
> www.qtworldsummit.com
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Please add [ChangeLog] entries to your commits!

[Kai Koehne]

Hi,

I just noticed that, out of the 61 commits in qtbase/5.9 that are not part of 
5.9.0, only one has a [ChangeLog] entry. 

Some of the commits are either changes to doc, or autotests, but for the rest: 
If it is not important enough to be mentioned to the user, why is the change in 
5.9?

Please be reminded that all changes that might be of interest to the end user 
should be part of the ChangeLog.  So please, whenever reviewing a change, 
please check whether a [ChangeLog] entry is in order.

Thanks

Kai

--
Kai Köhne, Senior Manager R | The Qt Company

The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der 
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

The Future is Written with Qt
www.qtworldsummit.com

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development