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

2017-02-13 Thread Tor Arne Vestbø 

On 13/02/2017 11:02, Edward Welbourne wrote:

Note that this speaks of "a changelog file" rather than tags in commits;
I do think this is a better approach, although I do also exhort everyone
to keep your changelog files organised on some *other* model than "make
each addition at the end" - e.g. sort by category, like the existing
ChangeLog tags, and put related changes near each other - since any
model that makes all additions at the same place *will* get conflicts
all the time.  Anything to ensure contemporary changes happen in
different places is better than always conflicting.


Git merge-drivers can be specified on a per file (pattern) basis, so a 
custom changelog driver could be used. We had something similar in 
WebKit for ChangeLog files.


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

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

2017-02-13 Thread Edward Welbourne 
Kai Koehne (10 February 2017 16:21) wrote:
> To sum the discussion here and also on gerrit up : There's no
> consensus on making [ChangeLog] entries mandatory, or making the
> [ChangeLog] field enabled by default.

Indeed.

> Anyhow, Ossi had an interesting third suggestion on
> https://codereview.qt-project.org/#/c/183244/:

>> how about this for an idea: we add a new gerrit category "ChangeLog"
>> which needs a +1. it would be auto-set by the bot if a changelog file
>> is touched, otherwise a reviewer needs to set it. easy to implement,
>> reliable (well, as much as the reviewers), and adds no noise to the
>> commit messages.

Note that this speaks of "a changelog file" rather than tags in commits;
I do think this is a better approach, although I do also exhort everyone
to keep your changelog files organised on some *other* model than "make
each addition at the end" - e.g. sort by category, like the existing
ChangeLog tags, and put related changes near each other - since any
model that makes all additions at the same place *will* get conflicts
all the time.  Anything to ensure contemporary changes happen in
different places is better than always conflicting.

> I understand that this would not be hard to do. This way nobody is
> forced to write changelog entries, but it requires a conscious click
> from the reviewer to say 'Yes, this does _not_ use a ChangeLog'.
>
> Any strong opinion against this?

Not from this quarter; if Ossi can teach Gerrit to remind me to think
about whether each change, that lacks one, wants a change log; that
sounds like a good solution to me.  Be sure to include a link to the
wiki page that says what tags to use and what should be in the change
log.

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

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

2017-02-10 Thread Kai Koehne 
Hi,

To sum the discussion here and also on gerrit up : There's no consensus on 
making [ChangeLog] entries mandatory, or making the [ChangeLog] field enabled 
by default.

Anyhow, Ossi had an interesting third suggestion on 
https://codereview.qt-project.org/#/c/183244/:

> how about this for an idea: we add a new gerrit category "ChangeLog" which 
> needs a +1. it would be auto-set by the bot if a changelog file is touched, 
> otherwise a reviewer needs to set it. easy to implement, reliable (well, as 
> much as the reviewers), and adds no noise to the commit messages.

I understand that this would not be hard to do. This way nobody is forced to 
write changelog entries, but it requires a conscious click from the reviewer to 
say 'Yes, this does _not_ use a ChangeLog'.

Any strong opinion against this?

Kai

> -Original Message-
> From: Schumann, Spencer [mailto:spencer.schum...@echostar.com]
> Sent: Thursday, January 26, 2017 5:11 PM
> To: Kai Koehne ; Oswald Buddenhagen
> ; development@qt-project.org;
> releas...@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  project.org> on behalf of Kai Koehne 
> Sent: Thursday, January 26, 2017 5:28:30 AM
> To: Oswald Buddenhagen; development@qt-project.org; releasing@qt-
> project.org
> Subject: Re: [Releasing] [Development] Change file process & improvement
> proposal
> 
> 
> 
> > -Original Message-
> > From: Releasing [mailto:releasing-bounces+kai.koehne=qt.io@qt-
> > project.org] On Behalf Of Oswald Buddenhagen
> > Sent: Thursday, January 26, 2017 12:52 PM
> > To: development@qt-project.org; releas...@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 " 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
> > releas...@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/releasing
> ___
> Releasing mailing list
> releas...@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/releasing
> 

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

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

2017-01-30 Thread Tor Arne Vestbø 


On 26/01/2017 13:28, Kai Koehne wrote:

So, any strong opinion against enforcing a [ChangeLog] line, with
"[ChangeLog] -" for commits that don't need one?


Yes. Absolutely not. This will just reverse the problem, creating noise 
in the commits and lots of useless ChangeLog entries, we might as well 
use git log directly.


tor arne

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

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

2017-01-27 Thread 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...@qt-project.org] On 
Behalf Of Schumann, Spencer
Sent: Thursday, 26 January 2017 5:11 PM
To: Kai Koehne ; Oswald Buddenhagen 
; development@qt-project.org; releas...@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 
>
 on behalf of Kai Koehne >
Sent: Thursday, January 26, 2017 5:28:30 AM
To: Oswald Buddenhagen; 
development@qt-project.org; 
releas...@qt-project.org
Subject: Re: [Releasing] [Development] Change file process & improvement 
proposal



> -Original Message-
> From: Releasing [mailto:releasing-bounces+kai.koehne=qt.io@qt-
> project.org]
>  On Behalf Of Oswald Buddenhagen
> Sent: Thursday, January 26, 2017 12:52 PM
> To: development@qt-project.org; 
> releas...@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
> " 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
> releas...@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/releasing
___
Releasing mailing list
releas...@qt-project.org
http://lists.qt-project.org/mailman/listinfo/releasing
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

2017-01-26 Thread Kai Koehne 


> -Original Message-
> From: Releasing [mailto:releasing-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Oswald Buddenhagen
> Sent: Thursday, January 26, 2017 12:52 PM
> To: development@qt-project.org; releas...@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
> " 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
> releas...@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/releasing
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

2017-01-24 Thread Kai Koehne 
> -Original Message-
> > [...]
> > 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
> >
> > https://codereview.qt-project.org/183244
> >
> > 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 needed".
> 
> [ChangeLog] none
> 
> or similar.

This will add quite some noise - There'll always be a significant portion of 
the commits, if not the majority, which do not require a ChangeLog. 

But yeah, it's easy to check and enforce :) I could live with this, too.

Kai

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

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

2017-01-24 Thread Frederik Gladhorn 
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@qt-
> > project.org] On Behalf Of Oswald Buddenhagen
> > Sent: Thursday, November 10, 2016 3:23 PM
> > To: development@qt-project.org; releas...@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):
> > 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
> 
> https://codereview.qt-project.org/183244
> 
> 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 
needed".

[ChangeLog] none

or similar.
At this point we'll be all constantly reminded to add change log entries and 
it's still reasonably easy to opt out.

Cheers,
Frederik

> 
> (who could do this?)
> 
> Regards
> 
> Kai
> 
> ___
> Releasing mailing list
> releas...@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/releasing


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