> ... resulting in users complaining about "high priority bugs get ignored".
They're still complaining? Impressive. I have already passed the phase of
resignation and
just wonder why there is still a public bug tracker.
--
Best Regards,
Bernhard Lindner
On Tue, Nov 03, 2020 at 10:34:29AM +, Alex Blasche wrote:
After all the trinity of quality - time - resources must be adhered to.
indeed, but you're still failing to draw the obvious conclusion. ;)
"priority inflation" is a "natural" effect of an issue tracker drowning
in unresolved issue
> On Nov 3, 2020, at 12:56, Eike Ziller wrote:
>
>
>
>> On Nov 3, 2020, at 11:34, Alex Blasche wrote:
>>
>>
>>
>>> -Original Message-
>>> From: Development On Behalf Of
>>> Jason McDonald
>>
>>> Looking at the huge list of P1s we have right now, I have absolutely no idea
>>> wha
On 3 Nov 2020, at 12:56, Eike Ziller
mailto:eike.zil...@qt.io>> wrote:
It is something that we interpret into a combination of two separated fields in
JIRA, with the meaning of Fix Version even having dual meaning depending on the
“Resolution” state of a task
Maybe we should have two fix ver
> On Nov 3, 2020, at 11:34, Alex Blasche wrote:
>
>
>
>> -Original Message-
>> From: Development On Behalf Of
>> Jason McDonald
>
>> Looking at the huge list of P1s we have right now, I have absolutely no idea
>> what issues are genuinely blocking Qt 6.0 or if there are any that I c
> -Original Message-
> From: Development On Behalf Of
> Jason McDonald
> Looking at the huge list of P1s we have right now, I have absolutely no idea
> what issues are genuinely blocking Qt 6.0 or if there are any that I could
> help out
> with. I could spend literally weeks just readi
On Tue, 3 Nov 2020 at 20:11, Alex Blasche wrote:
> Turns that there is a resolution overload in Jira. For any issue that was
> not transitioned into the closed state, the system sets the resolution
> field to "Unresolved".
>
> As soon as the closure happens, the resolution field is set to one of
Turns that there is a resolution overload in Jira. For any issue that was not
transitioned into the closed state, the system sets the resolution field to
"Unresolved".
As soon as the closure happens, the resolution field is set to one of the
predefined resolutions (e.g. Out of Scope, Duplicate
> On 3 Nov 2020, at 10:52, Richard Gustavsen wrote:
>
> Would it be better if we required all commits to have a ChangeLog entry, so
> that no one
> forgets? And if your commit shouldn't be in the log, you need to state that
> explicitly, e.g: [NoChangeLog]
No, that would just add noice to th
> But I didn’t like it when we generate a point-release changelog that says
> there are only minor changes, when I know for a fact that some significant
> bugs got fixed, and should be mentioned, even though the author forgot to
> add a ChangeLog to the git commit. So a few years ago, before each
Turns out I switched it on in some projects but not all. I simply forgot about
it.
I will rectify this during the next days. Please note that this will trigger
quite a few warnings about upcoming closure and it would give Jason a limited
window to resolve. Therefore this has to be in stages. Li
On Tue, 3 Nov 2020 at 18:48, Eike Ziller wrote:
> I disagree, especially if the fix version is a planning tool for the
> individual developer.
> The point is that you still at least need the rough categories of
>
> 1. must be handled _immediately_ (build breakage “P0”)
> 2. release management dec
On Tue, 3 Nov 2020 at 18:39, Allan Sandfeld Jensen wrote:
> On Dienstag, 3. November 2020 05:34:02 CET Jason McDonald wrote:
> > If an issue is not important enough to get attention within a year, is it
> > really P1?
>
> But how many of those are accepted? P1 is just set on the assumption the
>
> On Nov 3, 2020, at 09:07, Ulf Hermann wrote:
>
>> Currently, there are 1175 open P1 issues in the QTBUG project. 583 of those
>> issues had that priority set more than one year ago, 342 of those had their
>> priority set more than two years ago, and 175 of those more than three years
>> a
Il 03/11/20 05:34, Jason McDonald ha scritto:
Currently, there are 1175 open P1 issues in the QTBUG project. 583 of
those issues had that priority set more than one year ago, 342 of those
had their priority set more than two years ago, and 175 of those more
than three years ago.
If an issue
On Dienstag, 3. November 2020 05:34:02 CET Jason McDonald wrote:
> Some food for thought for module maintainers.
>
> Currently, there are 1175 open P1 issues in the QTBUG project. 583 of
> those issues had that priority set more than one year ago, 342 of those had
> their priority set more th
> On 3 Nov 2020, at 09:07, Ulf Hermann wrote:
>
>> Currently, there are 1175 open P1 issues in the QTBUG project. 583 of those
>> issues had that priority set more than one year ago, 342 of those had their
>> priority set more than two years ago, and 175 of those more than three years
>> ago
Currently, there are 1175 open P1 issues in the QTBUG project. 583 of
those issues had that priority set more than one year ago, 342 of those
had their priority set more than two years ago, and 175 of those more
than three years ago.
Let's be honest about this: The priority field is meaningle
18 matches
Mail list logo
