[Development] Long-lived P1 issues

Jason McDonald macadder1 at gmail.com
Tue Nov 3 10:12:13 CET 2020


On Tue, 3 Nov 2020 at 18:48, Eike Ziller <Eike.Ziller at qt.io> 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 decreed that this must be fixed for the (a) upcoming
> release (what P1 was supposed to be)
> 3. other issues
>
> Just if a fix version is set, this doesn’t mean 1 or 2, it just meant that
> someone thought it would be a good idea to fix it in this version, and this
> can change anytime.
>
> IMO tags are not very well integrated into JIRA to use it for 1 and 2, for
> one it would be difficult to find the tag to use - all tags are equal to
> JIRA, no grouping, nothing.
>
> If you use priorities 2-5 to prioritize issues in the 3rd category “other
> issues” or use fix versions for planning or whatever, is a different
> question.
>
> We had this discussion before and I still think we should make P1 actual
> blockers again, move all bugs one level lower that are not blockers, and
> then release management has to enforce the meaning of P1, as currently the
> meaning of “P1 with fix version” is enforced.
>

FWIW, I strongly agree with the above.

Having spent a lot of time on the release management side, I know that
release managers need to be able to tell the difference between issues that
absolutely must be fixed before a release can go out versus something
that's nice to fix and can be safely bumped if time is short and scope
needs to be reduced (which is almost always the scenario that a release
manager will find themself in when a deadline is looming).

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 reading through all
the P1s to try to figure out what's really important. I would not like to
be in the shoes of whomever has to make a go/no-go decision for Qt 6 in the
near future.

Cheers,
--
Dr. Jason McDonald
(macadder on FreeNode)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20201103/62755e46/attachment.html>


More information about the Development mailing list