Re: [Development] Long-lived P1 issues
On Fr, 2020-12-04 at 07:42 +0300, NIkolai Marchenko wrote: > Let's be honest with your users: > P0: almost sure to block a release. > P1: We will act on it if the maintainer is in the mood some day when it's > still fresh > P2: We will fix it, maybe > P3: thank you for informing us. Funny, this is pretty much how I would phrased it as well. -- Best Regards, Bernhard Lindner signature.asc Description: This is a digitally signed message part ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Long-lived P1 issues
> From: Development On Behalf Of NIkolai > Marchenko > Sent: Friday, December 4, 2020 9:45 AM > Subject: Re: [Development] Long-lived P1 issues > >> Currently, there are 1175 open P1 issues in the QTBUG project. 583 of those >> issues had that priority set more than one year ago, > > I am not saying no one ever fixes those, but given the premise of this > thread. The "promise" of every PX description is certainly > broken enough > _in general_ that my rewording is more accurate than official one. I think your interpretation is wrong. During this year we managed to close 1849 P1 issues in QTBUG [1]. At the same time 1966 P1 issues got reported [2]. So we indeed have a growing top-line of P1 tasks, and arguably also an issue with long-standing P1's. But for a new P1 that gets reported today, the chance that it gets closed in a timely manner is still rather high. Also, a lot of effort in 2020 was going into 6.0. I do expect we'll put some more focus on the bug backlog in 2021. Kai [1]: Obtained by JQL query 'project = QTBUG AND PRIORITY = "P1: Critical" AND resolutiondate >= 2020-01-01' [2]: Obtained by JQL query 'project = QTBUG AND PRIORITY = "P1: Critical" AND createdDate >= 2020-01-01' ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Long-lived P1 issues
> -Original Message- > From: Development On Behalf Of > Jason McDonald > Sent: Friday, 4 December 2020 5:25 AM > To: Kai Köhne > Cc: development@qt-project.org > Subject: Re: [Development] Long-lived P1 issues > > > On Fri, 4 Dec 2020 at 02:09, Kai Köhne <mailto:kai.koe...@qt.io> > wrote: > > > > Was there any outcome from this discussion? Like, re-evaluating > priority > > levels and what they mean in terms of release blockers? > > > > I note that the number of open P1's has dropped from 1175 to 1063. Some of > that decline has been from genuine P1's getting fixed for Qt 6, some is due to > maintainers doing some housekeeping, and I have closed a handful while > sifting through the older half of the Needs More Info bugs. > > > Thank you to everyone who has contributed so far. > > > There was no consensus, however, so I've put this on the backburner until I > can finish reading through the rest of the NMI bugs and the Testlib backlog, > which will take me into the new year. > > > When I'm done with those tasks, perhaps I can find one or two maintainers > who wouldn't mind a little help to straighten out their module's backlog in > exchange for educating me about their module. (Warning: I can only commit > to a maximum of ten hours per week for the foreseeable future.) > > Personally, I don't have a problem with the definitions of the priority > levels. > The only change I'd suggest is to make it explicit that the availability of an > easy workaround should generally cause the priority of a bug to drop down > one step. > > > What I'm seeing in Jira suggests that collectively we just aren't very strict > about sticking to those definitions. I've seen some cases where P1 has been > set to indicate that "this bug really annoys me" rather than "this bug > seriously > disrupts my work". I also see cases where the reporter set the priority > themselves. Back in the Nokia days, we had separate Severity and Priority > fields so that Jira could show both the level of disruption experienced by the > reporter and the urgency for a fix set by the maintainer. I'm afraid that I > can't > remember why we merged those fields. There was a discussion related to this recently: https://lists.qt-project.org/pipermail/development/2020-February/038988.html > > > I don't think there was any sort of decision or consensus. Which > means we keep working with the status quo, as documented in > https://bugreports.qt.io/secure/ShowConstantsHelp.jspa?#PriorityLevels > > I suggest to simplify P3, P4 descriptions though to > > P2: Important, should be fixed. > P3: Should be fixed. > > (the mentioning that they don't block a release probably stems from > a time where P1 meant blocking the release. This is not the case anymore, so > what's the point in highlighting that a P2, P3 doesn't block a release?). > > > > I think that would be a good change. P1's blocking a release only made sense > back in the days where we could only manage one release every three or > four months. > > > Cheers, > -- > Jason ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Long-lived P1 issues
> Currently, there are 1175 open P1 issues in the QTBUG project. 583 of those issues had that priority set more than one year ago, I am not saying no one ever fixes those, but given the premise of this thread. The "promise" of every PX description is certainly broken enough _in general_ that my rewording is more accurate than official one. On Fri, Dec 4, 2020 at 11:11 AM Joerg Bornemann wrote: > On 12/4/20 5:42 AM, NIkolai Marchenko wrote: > > > Let's be honest with your users: > > P0: almost sure to block a release. > > P1: We will act on it if the maintainer is in the mood some day when > > it's still fresh > > P2: We will fix it, maybe > > P3: thank you for informing us. > > That's neither helpful nor true. I certainly fixed many P3s in the past > - if not for recreational purposes, because I was working in the > respective area anyways. > > For issues that are low priority but hard to fix however... well as in > every project: bad luck. > > > Cheers, > > Joerg > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Long-lived P1 issues
On 12/4/20 5:42 AM, NIkolai Marchenko wrote: Let's be honest with your users: P0: almost sure to block a release. P1: We will act on it if the maintainer is in the mood some day when it's still fresh P2: We will fix it, maybe P3: thank you for informing us. That's neither helpful nor true. I certainly fixed many P3s in the past - if not for recreational purposes, because I was working in the respective area anyways. For issues that are low priority but hard to fix however... well as in every project: bad luck. Cheers, Joerg ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Long-lived P1 issues
Let's be honest with your users: P0: almost sure to block a release. P1: We will act on it if the maintainer is in the mood some day when it's still fresh P2: We will fix it, maybe P3: thank you for informing us. > I suggest to simplify P3, P4 descriptions though to >> >> P2: Important, should be fixed. >> P3: Should be fixed. >> > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development On Fri, Dec 4, 2020 at 7:27 AM Jason McDonald wrote: > > On Fri, 4 Dec 2020 at 02:09, Kai Köhne wrote: > >> > Was there any outcome from this discussion? Like, re-evaluating priority >> > levels and what they mean in terms of release blockers? >> > > I note that the number of open P1's has dropped from 1175 to 1063. Some > of that decline has been from genuine P1's getting fixed for Qt 6, some is > due to maintainers doing some housekeeping, and I have closed a handful > while sifting through the older half of the Needs More Info bugs. > > Thank you to everyone who has contributed so far. > > There was no consensus, however, so I've put this on the backburner until > I can finish reading through the rest of the NMI bugs and the Testlib > backlog, which will take me into the new year. > > When I'm done with those tasks, perhaps I can find one or two maintainers > who wouldn't mind a little help to straighten out their module's backlog in > exchange for educating me about their module. (Warning: I can only commit > to a maximum of ten hours per week for the foreseeable future.) > > Personally, I don't have a problem with the definitions of the priority > levels. The only change I'd suggest is to make it explicit that the > availability of an easy workaround should generally cause the priority of a > bug to drop down one step. > > What I'm seeing in Jira suggests that collectively we just aren't very > strict about sticking to those definitions. I've seen some cases where P1 > has been set to indicate that "this bug really annoys me" rather than "this > bug seriously disrupts my work". I also see cases where the reporter set > the priority themselves. Back in the Nokia days, we had separate Severity > and Priority fields so that Jira could show both the level of disruption > experienced by the reporter and the urgency for a fix set by the > maintainer. I'm afraid that I can't remember why we merged those fields. > > I don't think there was any sort of decision or consensus. Which means we >> keep working with the status quo, as documented in >> https://bugreports.qt.io/secure/ShowConstantsHelp.jspa?#PriorityLevels >> >> I suggest to simplify P3, P4 descriptions though to >> >> P2: Important, should be fixed. >> P3: Should be fixed. >> >> (the mentioning that they don't block a release probably stems from a >> time where P1 meant blocking the release. This is not the case anymore, so >> what's the point in highlighting that a P2, P3 doesn't block a release?). >> > > I think that would be a good change. P1's blocking a release only made > sense back in the days where we could only manage one release every three > or four months. > > Cheers, > -- > Jason > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Long-lived P1 issues
On Fri, 4 Dec 2020 at 02:09, Kai Köhne wrote: > > Was there any outcome from this discussion? Like, re-evaluating priority > > levels and what they mean in terms of release blockers? > I note that the number of open P1's has dropped from 1175 to 1063. Some of that decline has been from genuine P1's getting fixed for Qt 6, some is due to maintainers doing some housekeeping, and I have closed a handful while sifting through the older half of the Needs More Info bugs. Thank you to everyone who has contributed so far. There was no consensus, however, so I've put this on the backburner until I can finish reading through the rest of the NMI bugs and the Testlib backlog, which will take me into the new year. When I'm done with those tasks, perhaps I can find one or two maintainers who wouldn't mind a little help to straighten out their module's backlog in exchange for educating me about their module. (Warning: I can only commit to a maximum of ten hours per week for the foreseeable future.) Personally, I don't have a problem with the definitions of the priority levels. The only change I'd suggest is to make it explicit that the availability of an easy workaround should generally cause the priority of a bug to drop down one step. What I'm seeing in Jira suggests that collectively we just aren't very strict about sticking to those definitions. I've seen some cases where P1 has been set to indicate that "this bug really annoys me" rather than "this bug seriously disrupts my work". I also see cases where the reporter set the priority themselves. Back in the Nokia days, we had separate Severity and Priority fields so that Jira could show both the level of disruption experienced by the reporter and the urgency for a fix set by the maintainer. I'm afraid that I can't remember why we merged those fields. I don't think there was any sort of decision or consensus. Which means we > keep working with the status quo, as documented in > https://bugreports.qt.io/secure/ShowConstantsHelp.jspa?#PriorityLevels > > I suggest to simplify P3, P4 descriptions though to > > P2: Important, should be fixed. > P3: Should be fixed. > > (the mentioning that they don't block a release probably stems from a time > where P1 meant blocking the release. This is not the case anymore, so > what's the point in highlighting that a P2, P3 doesn't block a release?). > I think that would be a good change. P1's blocking a release only made sense back in the days where we could only manage one release every three or four months. Cheers, -- Jason ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Long-lived P1 issues
> -Original Message- >[...] > > (Clicking the ? button next to the priority field in Jira shows the > > following definition for P1: "Urgent and Important, will STOP the > > release if matched with set FixVersion field. This includes > > regressions from the last version that are not edge cases; Data loss; > > Build issues; All but the most unlikely crashes/lockups/hanging; > > Serious usability issues and embarrassing bugs & Bugs critical to a > > deliverable.") > > Was there any outcome from this discussion? Like, re-evaluating priority > levels and what they mean in terms of release blockers? I don't think there was any sort of decision or consensus. Which means we keep working with the status quo, as documented in https://bugreports.qt.io/secure/ShowConstantsHelp.jspa?#PriorityLevels I suggest to simplify P3, P4 descriptions though to P2: Important, should be fixed. P3: Should be fixed. (the mentioning that they don't block a release probably stems from a time where P1 meant blocking the release. This is not the case anymore, so what's the point in highlighting that a P2, P3 doesn't block a release?). Regards Kai ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Long-lived P1 issues
Hi, 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 is not important enough to get attention within a year, is it really P1? (Clicking the ? button next to the priority field in Jira shows the following definition for P1: "Urgent and Important, will STOP the release if matched with set FixVersion field. This includes regressions from the last version that are not edge cases; Data loss; Build issues; All but the most unlikely crashes/lockups/hanging; Serious usability issues and embarrassing bugs & Bugs critical to a deliverable.") Was there any outcome from this discussion? Like, re-evaluating priority levels and what they mean in terms of release blockers? Thanks, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Long-lived P1 issues
> ... 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 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Long-lived P1 issues
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 issues. this must be actively countered: - one must not allow oneself to be bogged down by feature requests. it is completely natural that more come in than can ever be resolved. - one must make a conscious effort to remain honest in evaluating the priority. this can be assistet by mandatorily using tools like user pain. - for that matter, i found the implementation of the bug triaging duty within tqtc (as still done two years ago) completely counterproductive, as one is often left with little more than guesswork, so no amount of honesty will help. - if after correct prioritization there is still an inflation in a priority level considered critical, then that is simply a cultural/management failure (or missing political will, as jason put it). ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Long-lived P1 issues
> 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 >>> 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 > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Long-lived P1 issues
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 version fields: intended and actual. It should be possible to automate tagging the actual fix version. And it should not be assumed that tagging the intended fix version means it’s a blocker, IMO, unless it’s marked with a high enough priority. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Long-lived P1 issues
> 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 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. 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 Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Long-lived P1 issues
> -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 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 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 Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Long-lived P1 issues
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 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) ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Long-lived P1 issues
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 > bug > is geniune, for instance reported crashes usually get P1. But if it can't > be > reproduced it might never get accepted. > That's a good point. 708 of the 1175 Open P1s are in the Reported state, i.e. if we're sticking to the defined lifecycle, those bugs are unconfirmed/untraiged. I find this rather worrying, since it seems to suggest that the majority of bugs that our users/customers believe to be P1 aren't getting triaged in a timely manner (or at all in a lot of cases). > > Also many modules are not maintained, is it in a module with an active > maintainer of group? > Clicking around randomly for a few minutes suggests that these are overwhelmingly in modules that aren't marked as inactive. I don't have any other way to tell which modules have active maintainers. > I was more confused when I found P0 that had been open for 10 months. That > wasn't really a P0. > That's also a little worrying. When I was Qt's release manager way back in 2008-10, I always had the list of open P0s open and regularly checked progress because those were the issues blocking the releases I was responsible for. At that time there were periodic discussions of having some automated process to ping the assignees of idle P0s after a short timeout. Cheers, -- Dr. Jason McDonald (macadder on FreeNode) ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Long-lived P1 issues
> 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 >> 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. I wonder why you don’t just set a different priority if you don’t agree with an issue being of so high priority that it _really_ should be fixed soon. > 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. 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. Br, Eike > 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 > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Long-lived P1 issues
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 is not important enough to get attention within a year, is it really P1? The priorities used to be related to the _technical_ importance of a task: f.i. a regression or a crash is a P1. That, unfortunately, has nothing to do with the political will of 1) actually working on fixes for P1 before P2/P3/new features/whatever 2) actually blocking a release if P1s are not solved (and if they aren't, comment on them as of why they're missing a release) ... resulting in users complaining about "high priority bugs get ignored". So, sure, there may be issues that are wrongly classified as P1, but saying "it's not a P1 because it's not been fixed for a while" doesn't match what P1 used to mean. If you want to change priorities so that they become a "this issue should get urgent attention, this other not so much", then it becomes a completely arbitrary decision; you could just drop the field entirely as far as I'm concerned. My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Long-lived P1 issues
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 than two years ago, and 175 of those more than > three years ago. > > If an issue is not important enough to get attention within a year, is it > really P1? > > (Clicking the ? button next to the priority field in Jira shows the > following definition for P1: "Urgent and Important, will STOP the release > if matched with set FixVersion field. This includes regressions from the > last version that are not edge cases; Data loss; Build issues; All but the > most unlikely crashes/lockups/hanging; Serious usability issues and > embarrassing bugs & Bugs critical to a deliverable.") > But how many of those are accepted? P1 is just set on the assumption the bug is geniune, for instance reported crashes usually get P1. But if it can't be reproduced it might never get accepted. Also many modules are not maintained, is it in a module with an active maintainer of group? I was more confused when I found P0 that had been open for 10 months. That wasn't really a P0. 'Allan ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Long-lived P1 issues
> 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. > > Let's be honest about this: The priority field is meaningless. We still sort by priority when we go intentionally looking for bugs to fix, though, don’t we? That just hasn’t happened much lately, because of being in such a hurry to get as much Qt 6 work done before the various deadlines that are all coming up way too soon. During bug fix weeks, of course customer-reported bugs come first, but otherwise we sort by priority to find bugs to fix. Of course anyone in the community is welcome to give it a try too. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Long-lived P1 issues
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 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Long-lived P1 issues
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 than two years ago, and 175 of those more than three years ago. If an issue is not important enough to get attention within a year, is it really P1? (Clicking the ? button next to the priority field in Jira shows the following definition for P1: "Urgent and Important, will STOP the release if matched with set FixVersion field. This includes regressions from the last version that are not edge cases; Data loss; Build issues; All but the most unlikely crashes/lockups/hanging; Serious usability issues and embarrassing bugs & Bugs critical to a deliverable.") Cheers, -- Dr. Jason McDonald (macadder on FreeNode) ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
