> On Nov 3, 2020, at 12:56, Eike Ziller <[email protected]> wrote: > > > >> On Nov 3, 2020, at 11:34, Alex Blasche <[email protected]> wrote: >> >> >> >>> -----Original Message----- >>> From: Development <[email protected]> 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 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. >> >> I don't believe reserving P1 for release blockers (as suggested by Eike) >> solves this problem. A release blocker for timed releases (which is what >> Qt's been doing for years) is not just a prio field but also a timing issue. >> After all the trinity of quality - time - resources must be adhered to. >> Resourcing is generally fixed for a release, the prio field reflects quality >> and "fix Version" field maps to time. Therefore we have to make tough calls >> to leave some P1 bugs out as time runs out. Therefore the blocker list for a >> release is a combo of Fix version and prio >> >> Here is Jani's link for them: >> https://bugreports.qt.io/issues/?filter=22682 > > I think that this split is very hard to see, realize and understand at the > minimum for non-Qt-developers / customers / users, and sometimes even for > developers. > 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, it requires a custom filter to see which > tasks actually were important enough to warrant some of the resources for a > fix in the next version. > > Also it introduces a split within the P1 tasks: Some of them are were deemed > more severe than others, so we committed to allocating resources to them (by > setting a fix version), and some were considered less important. > > It is simply easier to see, if this is reflected in the priority. Will my > issue be fixed? > > P0: Yes, as soon as possible. > P1: Yes, it was deemed important enough to be allocated resources so it > should be fixed in the next release. or P1: Yes, it was deemed important enough to block the next release so it should be fixed in the next release. Since my suggestion is to make P1 == release blocker == there need to be resources allocated at some point if there is to be a release.
> P2-P5: No idea. > > In the P2-P5 range differences in priority, timing/fix version whatever, can > still be used to differentiate. > > Br, Eike > >> >> The priority field is a standard field. There is no way to remove it. One >> can hide it somewhat but it is known to show up in different places. Mind >> you, our triaging process is based on unset prio fields. We check for data >> to assess the prio and ask for more until we can set the prio. It still >> doesn't imply that we can verify the bug on our side. One could do that too >> but this will expand the scope of triaging significantly and I am not sure >> whether we want to go this far. >> >> -- >> Alex > > _______________________________________________ > Development mailing list > [email protected] > https://lists.qt-project.org/listinfo/development _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
