[Development] Long-lived P1 issues

[Ulf Hermann]

> 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 meaningless. There 
have been so many P1 issues that didn't stop any release that many 
people, including me, just ignore P1 by now. Furthermore, anything below 
P2 effectively means "we're never going to fix it". There is no point in 
having 3 different priorities for that. The only priority that still 
prompts an immediate reaction (from me at least) is P0, as those are 
usually build failures that block work elsewhere.

I currently use a combination of tags and the "Fix version" field to 
prioritize my own tasks.

To summarize, the actual meaning of priorities, as perceived by me, is 
as follows:

Unprioritized: See magic tags, fix version, etc
P0:            Immediate action on the way
P1, P2:        Will probably get fixed sometime
rest:          Won't be fixed unless it has magic tags, fix versions ..

That's not only quite different from the documented meaning of the 
priorities but even if it was documented that way, it wouldn't convey a 
clear message to any observers. In particular, you have no idea what 
time frame to expect when a bug has P1 or P2.


Here is a proposal to improve this situation:

Drop the priority field and instead use the fix version universally.

The fix version is a clear enough indication of the urgency of a task. 
It prompts you to reconsider all bugs that slipped once a new version 
has been released. It doesn't force you to bump the fix version on every 
release, but a bug with a past fix version that isn't fixed is clearly 
abandoned. That's in contrast to a 3 year old P1 bug that isn't fixed. 
For the latter, as an observer, you have no idea what the actual status is.

Tasks that currently receive P1 or P2 will then have a fix version of 
the next release they qualify for. That would be 6.0 for bugs at the 
time or writing, or 6.1 for new features. If the task qualifies for 
fixing in LTS, you'd additionally set the next LTS release(s) as a fix 
version. Tasks with lower priority will have something like 6.x to 
signal "sometime in the Qt6 time frame". This way, it is also possible 
for individuals to plan work ahead in a more fine grained way and set, 
for example, 6.2 as fix version.

We may need an "immediate action required" tag in addition, to signal 
the current meaning of P0.

best,
Ulf