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 thes
On Wed, Jan 25, 2017 at 10:21:09AM +0100, Edward Welbourne wrote:
>> However, you seem to be talking about *release* 5.x.0 rather than the
>> *branch* of that name, so I'm not really clear on what you're talking
>> about.
25 January 2017 12:13, Oswald Buddenhagen:
> i don't know how you arrived at
On Wed, Jan 25, 2017 at 10:21:09AM +0100, Edward Welbourne wrote:
> However, you seem to be talking about *release* 5.x.0 rather than the
> *branch* of that name, so I'm not really clear on what you're talking
> about.
>
i don't know how you arrived at this conclusion, but it isn't relevant
to my
> On 25 Jan 2017, at 10:21, Edward Welbourne wrote:
>
> I have never heard of these amends lines; where are they
> explained ? In any case, users may find a change interesting even if
> there is no specific earlier commit that can be pinned down as what this
> new change amends - sometimes, th
On Tue, Jan 24, 2017 at 03:38:11PM +0100, Edward Welbourne wrote:
>>> Proposal: Check for [ChangeLog] entries in a 5.x branch _after 5.x.0
>>> branched_. Is that easy to enable/disable?
>>
>> It should be easy to detect that 5.x.0 "has branched" - check for
>> existence of either origin/5.x.0 branc
On Tue, Jan 24, 2017 at 03:38:11PM +0100, Edward Welbourne wrote:
> > Proposal: Check for [ChangeLog] entries in a 5.x branch _after 5.x.0
> > branched_. Is that easy to enable/disable?
>
> It should be easy to detect that 5.x.0 "has branched" - check for
> existence of either origin/5.x.0 branch
> Proposal: Check for [ChangeLog] entries in a 5.x branch _after 5.x.0
> branched_. Is that easy to enable/disable?
It should be easy to detect that 5.x.0 "has branched" - check for
existence of either origin/5.x.0 branch or v5.x.0 tag. That we're
committing to 5.x is fairly easy *in Gerrit* (wi
@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
>
On Thu, Nov 10, 2016 at 12:38:41PM +, Jani Heikkinen wrote:
>> Lately it has been quite hard to get change files done for the releases.
and Ossi replied:
> oh, it's that time of the year again. :D
Speaking of which, it's also hard to get API reviews done, even though
they are now much easier (
On Thu, Nov 10, 2016 at 12:38:41PM +, Jani Heikkinen wrote:
> Lately it has been quite hard to get change files done for the releases.
>
oh, it's that time of the year again. :D
> 1) Let's enable [ChangeLog] -tag by default in commit template. After
> that you must remove/comment out it by pur
Hi all,
Lately it has been quite hard to get change files done for the releases. It
should be maintainers responsibility to make sure those will be done for every
release and those are containing proper data. We have tried to help maintainers
by doing initial ones for them (running script to co
11 matches
Mail list logo
