Re: [Development] Please add [ChangeLog] entries to your commits!
> -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&D | 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
Re: [Development] 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 ...) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Please add [ChangeLog] entries to your commits!
> -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
Re: [Development] Please add [ChangeLog] entries to your commits!
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!
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!
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!
> -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!
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